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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: CSS and XSL?, Chuck Robey | Thread | Re: CSS and XSL?, Chuck White |
General Architecture, Smith, Adrian | Date | Re: CSS and XSL?, Chuck White |
Month |