Re: Default XSL stylesheet for XHTML documents

Ian Hickson wrote:
> 
> On Mon, 2 Oct 2000, Chris Lilley wrote:
> 
> >> I can easily see using XSLT+XSL-FO to lay out a complete book. I
> >> can't see doing that with CSS.
> >
> > I agree. Unless of course one is permitted to transform the input XML
> > to some other XML, before styling it with CSS.
> 
> Why on earth would one NOT be permitted to transform XML into some other
> XML before styling it with CSS?

Its called rhetoric, Ian ;-)

> XSLT is great! In fact XSLT is absolutely *essential* to styling pure
> structural XML using CSS!

No, it isn't essentiual. Its a transformation tool, byut so is awk, or
Perl, or server-side Java DOM servlets, or any number of things.

> I have *nothing* against transformations.
Exactly. Well actually, I do have something against client-side
transformations in that the resulting thing is not a resource - it has no
address, no URL, no addressability.

> The problem with XSL:FOs is that there is no user control. You can create
> pure XSL:FO documents on the web! And as soon as browsers grok XSL:FO,
> that will happen, because there is no user stylesheet! XSL:FO puts the
> author in charge instead of the user. No more user-stylesheet to increase
> the font-size of headers and force the colours to be high-contrast.
Yes, I know.
 
> Furthermore, XSL:FO removes all semantics from the document! A pure XSL:FO
> document is un-indexable, cannot be transformed into another, more useful
> document, cannot be processed by a UA using another media.
I know.

> Another problem with XSL:FOs is that the DOM is the DOM of the formatting
> objects, so you cannot have a single application that can expect a single
> DOM to play with, but style it using different stylesheets depending on
> the mood of the reader.
I know.

> The features that XSL:FOs have that are missing from CSS should be added
> to CSS. The serious problems with XSL:FOs are not anything to do with what
> formatting features it has, nothing to do with how well it lays out a
> page, they are problems with the underlying philosophy of the language.
I understand. This is not news to me. I don't think the batch-orientation
makes for good styling for interaction. But it makes fine sense for print.
And I don't have a problem with my browser fetching an XSL stylesheet and
executing it to make a PDF file or whatever when I hit the print button.

> >> and bring it to the local print shop while CSS doesn't.
> > Well clearly it does - for example, the PDF version of the CSS2 spec
> > was produced by a CSS processor, and that in 1998 - but without as you
> > say footnotes and endnotes. The TOC and indexes were auto generated,
> > as one would in XSL-T (not *with* XSL-T, though, with Perl).
> 
> So the main selling point of FOs (they can be used to make PDFs but CSS
> cannot) is not true?
CSS can clearly be used to make PDFs. Whether it can make
publication-quality print is another matter.

> > Yes, clearly one can produce high quality printed matter with one of the
> > commercial XSL FO renderers now available. In some ways that is the
> > important thing - not which spec can do/could do/can't do what but which
> > implementations are out there and suffiuciently good to be worth using.
> 
> No, the important thing is the user, and accessibility. How do XSL:FOs
> help blind people?
How does the print stream in your print queue help blind people?

> XSL:FOs are, IMHO, a serious risk to a significant minority of the
> population.
No, server-side styling is what poses that risk. Its possible to pose
exactly the same risk using CSS (whether the CSS is rendered client side or
server side). Just convert all of your rich XML into a flat XML tree with
one element called foo and an id on each element and a style sheet that
sets the size, color etc of each element.

> Data made of pure presentational markup should, IMHO, not be published.
Rubbish (as a blanket statement without provisos). It depends on what it is
for. It depends on an adequate definition of 'semantic'.

> And certainly not alone. Documents should always be published either in
> well known semantic-full vocabularies (XHTML, MathML, even SVG to some
> extent) 

Uhm, in what way is XHTML 'semantic'. I agree that half of the MathML spec
(the lesser-implemented part) is semantic.

> or in propriatary XML vocabularies tailored to the application
> along with an XSLT file to convert the data _into_ well known semantic-
> full vocabularies.
> 
> It is vital that even without a CSS or XSLT->XSL:FO stylesheet, the
> document still be viewable using the UA stylesheet on any media.
> 
> XSL:FOs do not allow that.
Your entire argument is predicated on the conversion being done on the
server. As to how that is different from the current situation, where all
sors of rich information is converted to crap HTML on the server, its
difficult to see.

--
Chris

Received on Monday, 2 October 2000 18:12:23 UTC