Re: CSS and XSL?

Subject: Re: CSS and XSL?
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Thu, 10 Jun 1999 18:31:02 +0200
Didier PH Martin <martind@xxxxxxxxxxxxx> wrote:

>This said, did someone have read this note. And what is your opinion on
>this?
>
>http://www.w3.org/TR/NOTE-XSL-and-CSS

I have read it and I don't like it much. This is going to be longish - but
then, you asked :-)

Options 1-3 which Hakon describes are what everyone does today (use XSLT to
transform to either XML or HTML with CSS annotations, doing the
transformation either on the client or on the server). Of course some people
use XSLT to transform XML to XML regardless of presentation, which while
highly useful is beyond the scope of the note - we want to discuss
presentation.

Option 4 which Hakon suggests is to define XML syntax for CSS formatting
objects. There are two differences between this and transforming to XML+CSS
(as defined today):

- The output elements are all <css:chunk> etc. instead of using domain tags.
I view this as a disadvantage; I'd like to be able to preserve semantics if
I want to, and to encourage people to do so by default. Of course that if
someone wants to remove the semantics, he can always transform all elements
to the same XML tag - dare I say <SPAN>? - and achieve the same effect.

- The output is XML instead of using the current CSS syntax. XML syntax is
presumably easier to generate via XSLT. Note that it is perfectly possible,
and even easy, to generate current CSS syntax from XSLT. I've been doing it
quite a while now, together with generating JavaScript code to manipulate
the resulting DOM at run time. I doubt that anyone would suggest defining an
XML syntax for generating JavaScript - <js:if test="...">, anyone?

XSLT and CSS can live pretty happily together as things stand now, and in
fact do so all the time in existing applications. If the whole purpose of
the excersize is to make it easier for them to work together, I doubt it is
worth the effort.

Of course, one can choose a different goal - not only allowing XSL to emit
CSS as output, but to handle it as input. This isn't quite as crazy as it
sounds. Chaining stylesheets should be a perfectly valid operation. Today
applying an XSLT stylesheet to XML+CSS is an excersize in frustration.

There's another goal, which is more abstract - do not define multiple
standards for achieving the same effect. Here the CSS/XSL/XML combination
fails on several accounts:

- XML defines one way to textually represent hierarchical data, CSS uses a
different syntax. None is that much better then the other, and having two
just muddles the works (for example, two separate tool sets - editors,
parsers, pretty printers, you name it).

- XSL (and now merged with XPointer, and hopefully XQL) defines a very rich
way to identify XML elements. CSS has its own selectors syntax which do the
exact same thing. Again, this means two separate tool sets. Note that we
used to have three W3C standards for this - XSL, XPointer, and CSS. The same
arguments which held for merging XPointer with XSL patterns should hold for
merging/replacing CSS pattern syntax, right?

- XSL defines its own FOs set. Actually, I'm all for dumping then in favor
of a better CSS standard (and the CSS standard is improving, even if
implementations are not), or at least declaring them as XML's replacement
for PDF (something which is very useful - not everything must live in a
browser!).

Note that CSS does provide some things no other standard does, and therefore
has its own place in the XML standards soup. The ability to _dynamically_
manipulate presentation _rules_, for example, does not exist anywhere else.
This ability is crucial for interactive applications.

>After having heard about the thesis and the antithesis what about the
>synthesis?


A strong synthesis would be to define an alternate XML syntax for CSS (using
XSL patterns, of course) and define CSS3 using the new syntax. CSS1 and CSS2
semantics would be defined by transformation to this new syntax. Existing
documents with CSS syntax would be handled by XML tools (in particular, XSLT
processors) as if they were written in XML in the first place, using a
conversion layer.

A merely adequate synthesis would be to (gulp) accept CSS syntax as part of
XML processing - at least to the degree that XML parsers would recognize it
and produce the appropriate DOM tree (or SAX events) - including translation
of the CSS selectors to XSL/Xpointer/XQL patterns. This is almost what is
currently done in every browser supporting DOM and CSS, anyway. We'd double
the size of XML parsers, but at least we'd avoid doubling everything else.

A weak synthesis is what we have today. Separate XML and CSS parsers,
separate XML and CSS validators, separate XML and CSS editing code, separate
XML and CSS pattern matching code - separate XML and CSS everything - but
with the two always working together, somehow, typically within the same
program/tool. Makes you pity browser and tool implementers, really. As if
their life aren't difficult enough as it is.

But even a weak synthesis is better then none at all. After all, what's a
mere doubling of complexity these days? Things could have been much worse, I
suppose...

Have fun,

    Oren Ben-Kiki


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread