Closed Bug 109684 Opened 23 years ago Closed 14 years ago

Add support for displaying DocBook documents out-of-the-box...

Categories

(Core :: DOM: HTML Parser, enhancement, P4)

Product:
Core
Component:
DOM: HTML Parser
Type:
enhancement

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: roland.mainz, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted, Whiteboard: [bae:2001121003][WONTFIX?]) 

RFE: Add support for displaying DocBook documents "out-of-the-box", e.g. without
setting an explicit stylesheet within the document itself.
(we can use the DocBook-->XHTML XSL stylesheet available from
http://sourceforge.net/project/showfiles.php?group_id=21935 for this... :-)
Over to layout for consideration
Assignee: asa → attinasi
Component: Browser-General → Layout
QA Contact: doronr → petersen
Target Milestone: --- → Future
sounds like a cool template
Keywords: helpwanted
Priority: -- → P4
Whiteboard: [bae:2001121003]
What are the problems with this bug ?
We only have to implemenent two things:
1. Detect that a document is a DocBook one
2. Apply the XSL stylesheet

... or do I miss something here ?
It has nothing to do with the request being wrong, it just has to do with 
priorities of the assigned engineer. If someone in the mozilla community can 
help with this, then the odds are it will get addressed sooner and checked in 
sooner, that is why I added the helpwanted.
->Parser, to address Roland's point #1.  Maybe this should depend on the
"Implement XML Catalogs" bug?
Assignee: attinasi → harishd
Component: Layout → Parser
QA Contact: petersen → moied
Its a little trickier than that, because the latest XSL stylesheet for DocBook
causes Mozilla 1.2b to hang. At least on Windows anyway.
Blocks: 200958
The suite of bug 98413 and bug 92452 should make this something like a mozdev
project.
Whether this invalidates, dupes or depends doesn't matter to me. I would expect
any other path to get WONTFIX'd, though.
*** Bug 200958 has been marked as a duplicate of this bug. ***
Re: point 1. in comment #3 and comment #7

XML catalogs help with parsing external entities. However, using public ids for
determining DocBookness is questionable. See
http://lists.w3.org/Archives/Public/www-html/2000Jan/0180.html

Since sniffing for the root element namespace is not possible with DocBook, I
suggest using HTTP Content-Type or file name extension on local disk for
determining whether a document should be treated as DocBook document. I suggest
considering the MIME type application/x-docbook+xml and (in the absence of a
MIME type) the file name extension .dbk as indications of DocBookness.

Should I open a new bug on the method used for determining DocBookness?
> Since sniffing for the root element namespace is not possible with DocBook

Actually the DocBook guy has said he would consider defining a root element
namespace for us if we needed it. So it could be possible if we really were
serious about supporting DocBook. Are we? (And by that I mean, would the module
owners approve such support?)
ccing said module owners...  See comment 10.
I'd definitly be fine with adding DocBook support. Though it is a bit tricky
since XSLT changes the DOM which we can't do for all loaded docbook documents
since they might have been loaded for reasons other then pure display.

So it's more or less the prettyprint problem again...
Given comment 10, why wouldn't a simple stylesheet do the trick?
are you talking about CSS or XSLT stylesheets? If it's possible to display
DocBook using simply CSS then absolutly. However if XSLT is required we're
running into the same problems as prettyprint did
Would I ever suggest XSLT?
Ian 'Hixie' Hickson wrote:
> Given comment 10, why wouldn't a simple stylesheet do the trick?

Only if you use XSLT stylesheets... using CSS won't work for DocBook links and
other more complex DocBook stuff.
Hehe :)

However, is there such a thing as a CSS stylesheet that makes DocBook readable?
Docbook links would just be implemented in the one place where all links (html
links, xlinks, etc) are implemented. (We do have just one place, no? I remember
saying about 5 years ago that we should just have one place. I assume we have
just one place by now. If not then it's about damn time we got there.)

What other more complex stuff?
(In reply to comment #18)
> (We do have just one place, no?

No.  The xlink semantics are sufficiently different from HTML link that you need
a good deal of separate code for them no matter what you do.  The end result
ends up being the same (as in, you end up with a URI and a target and a time to
trigger it), but finding those three pieces of data is a totally separate
process for the two.

In fact, it's likely to be a totally separate process for docbook links too. 
Not as different as xlink, so possibly mergeable with HTML to some extent.  But
different enough to require separate code.

-Boris
also, i'm not sure that i want to add element-classes and a lot of other c++
code specific for DocBook. I'd rather see a general solution like bug 98413 or
bug 92452 where adding DocBook support only requires adding an entry in some
table and including a set of stylesheets.

However, maybe XBL could be used to do the parts of DocBook that CSS can't
handle. Though such XBL and CSS most likly does not exist yet.
Actually, creating "docbook anchor" XBL that would just stick an anonymous
<html:a> around the contents of the docbook link should not be too bad, unless
docbook links have very different semantics...
The DTD stuff wouldn't work since the idea is to use namespaces here (i.e. you
might not have a DOCTYPE).

The XBL-for-links stuff wouldn't work either, since you want Docbook links to
match :link/:visited.
The <a> in the XBL would match those, no?
Would you consider it correct if the following:

   * { border: blue solid; }
   :link, :visited { border: green solid; }

...put two borders around every link?
Heh.  That seems like a serious shortcoming of XBL... (especially for hyatt's
plans to implement XHTML2 with it...)
Ian 'Hixie' Hickson wrote:
> What other more complex stuff?

Two examples:
Tables use a completely different model (CALS) than HTML... and some items like
QANDASET require an index to be build... and I doubt CSS can do that...
And actually, a binding that extends xhtml:a and does some stuff right but
doesn't have <content>, combined with some changes to the style system code
_may_ be able to deal there.  That would require moving link triggering out of
HandleDOMEvent, which means waiting on bryner's event dispatch rewrite.
XBL wasn't intended to make elements match pseudo-classes. Doing that would be
affecting the semantics of the language in question, which is a no-no. (Not to
mention that you need to be matching pseudo-classes before you apply the
bindings, since you use CSS to apply the bindings.)

That doesn't mean you can't implement XHTML2 using XBL, it just means you need
to implement the core semantics natively (or in some extension mechanism that
comes in before CSS). XBL is just a behaviour and presentation extension mechanism.
> Tables use a completely different model (CALS) than HTML...

DocBooks tables are different, but a good approximation can be made with CSS.


> and some items like QANDASET require an index to be build...

I don't see why <qandaset> requires an index.


Supporting DocBook completely, including event handler attributes and so forth,
would require C++ code either way. The question is can an approximation be made
using just CSS, and whether this is interesting.
Ian 'Hixie' Hickson wrote:
> > Tables use a completely different model (CALS) than HTML...
>
> DocBooks tables are different, but a good approximation can be made with CSS.

If you replace the "good" with "bad" both I and Simo will agree with you....
=:-)
CSS is _FAR_ away from being able to handle docbook tables in a reasonable way.

> > and some items like QANDASET require an index to be build...
>
> I don't see why <qandaset> requires an index.

Uhm... did you ever used a real DocBook viewer ? Sure... you always can display
DocBook like "lynx" outputs HTML... but I am not sure whether this was the goal
of this bug.
Just a though: Can DocBook attach stylesheets? If not, are stylesheets like the
ones in comment 24 really a problem?

Are we talking about adding support for mixing DocBook stuff with
XHTML/SVG/MathML etc etc? Was DocBook even designed to do that? If not, maybe
we're overdesigning here.
(In reply to comment #30)

> CSS is _FAR_ away from being able to handle docbook tables in a reasonable way.

Not that _FAR_, maybe just far, if by "reasonable way" you mean the subset of
CALS specification that seems to be commonly used in technical manuals.

Mainly, col/row spanning and how it is marked up in the document is a problem
because spanning isn't natively supported by CSS2. Of course, CALS tables often
do use spanning and even the HTML COLSPAN/ROWSPAN scheme is nothing compared to
CALS's spanning, feature- and complexity-wise. Among other few things, we
handled that internally in C++ for DocZilla.

After you've got the structure of the CALS table presented nicely on the screen,
CSS can provide for most of the visual layout rules you're going to need.

I guess if what this bug is asking for is a comprehensive DocBook viewer then 
I'm not really interested in seeing this on the trunk. I was under the 
impression it was just asking for a basic viewer. A complete implementation 
would be best done as an extension.
DocBook NG is in a namespace: http://docbook.org/docbook-ng

(I still consider doctype sniffing on the XML side harmful and plain wrong and
think Mozilla should avoid it.)
Assignee: harishd → nobody
QA Contact: moied → parser
For the sake of interoperability (I see no signs of other Web browser wanting to become DocBook browsers) and footprint (DocBook support isn't free), I suggest WONTFIXing this.
Whiteboard: [bae:2001121003] → [bae:2001121003][WONTFIX?]
Agreed
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.