Re: Default XSL stylesheet for XHTML documents

Elliotte Rusty Harold 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.

> 1. Page numbers!   XSL-FO makes it straight-forward not only to
> insert the current page number but to cross-reference to numbers of
> other pages. This is essential for building tables of contents,
> indexes, cross-references, and more.

Agreed, vital for print. For online Web usage, that is what links are for.

> 2. Footnotes and other floating objects.

CSS has floats too, but 'horizontal' (inline progression direction) floats
as opposed to vertical (block progression direction) floats.

> 3. Running headers and running footers. Every book has these. I don't
> see them in CSS.

They narrowly missed being in CSS2. In consequence, there are at least
three incompatible CSS2 extensions that produce headers and footers. Which
shows it can be done, though it would have been better to have a single
standard way to do it rather than three non-standard ways.

> 4. More granular properties. Many CSS properties are just shorthands
> for more detailed XSL-FO properties.

Yes, and then with traits it becomes even more granular.

> 5. Much better support for non right-to-left, top-to-bottom text;
> including text that mixes writing directions.

Much of which is also in CSS3. Note that there is nothing intrinsically
wrong with saying "left" as long as it really means "left" and not "top" or
"right" or "inline progression direction".

> And of course there are the practical issues like the fact that
> XSL-FO lets me produce a high-quality PDF 

Yes, that definitely seems to be where FO has taken off - commercial
products that read XSL FO and output PDF.

> 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).

> Some of these are fixable problems, and
> some of them will likely be fixed (though I'm really curious to know
> how CSS could even begin to handle page number citations and
> cross-references) but I still expect that I'll be publishing printed
> books with XSL-FO long before I can think about doing that with CSS.

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.

CSS is now getting some usable Web/online/editing implementations and XSL
FO is getting some usable print/offline/static implementations. Which tends
to imply, in the real world, that @media print is better pointing at an XSL
stylesheet and @media screen is better pointing at CSS - purely on the
basis of probability.

> CSS may be enough for the Web, but I don't think it's enough for print.

Its tempting to reverse that and ask, XSL is good enough for print, but is
it good enough for the Web? I'm thinking here of :link (and, in CSS3,
:target) for use with XLink, and SMIL animation. And the fact that a
client-side transformed XML document has no URL, can't be pointed to, etc.
These are the sorts of things which are irrelevant in the print world, and
highly relevant in the Web world.

It may be nearing the time when we stop bickering and comparing the length
of our collective body parts, and just get on using each tool for the
purpose to which it is best suited.

--
Chris

Received on Monday, 2 October 2000 16:42:45 UTC