- From: Ian Hickson <ianh@netscape.com>
- Date: Mon, 2 Oct 2000 14:25:27 -0700 (Pacific Daylight Time)
- To: Chris Lilley <chris@w3.org>
- cc: Elliotte Rusty Harold <elharo@metalab.unc.edu>, www-style@w3.org
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? XSLT is great! In fact XSLT is absolutely *essential* to styling pure structural XML using CSS! I have *nothing* against transformations. 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. 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. 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. 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. >> 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? > 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? XSL:FOs are, IMHO, a serious risk to a significant minority of the population. Data made of pure presentational markup should, IMHO, not be published. And certainly not alone. Documents should always be published either in well known semantic-full vocabularies (XHTML, MathML, even SVG to some extent) 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. -- Ian Hickson )\ _. - ._.) fL Netscape, Standards Compliance QA /. `- ' ( `--' +1 650 937 6593 `- , ) - > ) \ irc.mozilla.org:Hixie _________________________ (.' \) (.' -' __________
Received on Monday, 2 October 2000 17:22:18 UTC