Fw: W3C-transformation language petition
Ian Hickson <py8ieh@xxxxxxxxxx> wrote: >This is my first post here. I've been lurking for some time, and I >feel there are some misunderstandings within the XSL community as to >what CSS can do and especially how its syntax works. We are all here to learn :-) >... > >What about an aural rendition? > >Will XSL be able to cope with alternative (non graphic) media? CSS >can. This is quite an important issue. Good question. I'd say CSS is better suited to handle alternative media the FOs are. FOs are designed around a 2D graphic layout paradigm. In CSS, one could add new "display" types and their related attributes. >> The only problem is that CSS does not provide the full set of >> attributes necessary. > >Quite seriously, what is it that in the opinion of FO proponents is >missing from CSS? (Other than tree transformation, obviously.) Well, FOs handle pages better, handle international languages better, and so on. Nothing CSS couldn't in theory do, it is just that the relevant attributes and air-tight semantics haven't reached the standards yet - not to mention the implementation. I imagine the print people would have a lot to say about this issue :-) >And now the *really* off-topic part: > >> And, of course, the syntax of CSS should be replaced by an XML >> compliant one :-) > >I know that some people feel this quite strongly. Guilty :-) >The reasons I have seen put forward basically boil down to "You don't >need Yet Another Parser". That's almost it, but not quite. The problem is that the DOM <=> XML mapping is no longer simple. It becomes different for CSS data. The DOM API would no longer be sufficient, by itself, to be able to generate a correct XML tree for the document, and the SAX events for parsing the XML document would no longer be sufficient for building the in-memory DOM. I find this very disturbing. Oh, one could work around this - demand that every XML parser/emitter would know to switch formats in mid-stream to handle CSS. Think of the consequences if each time an extension was made to vanilla XML 1.0, a new syntax was introduced - a new one for name spaces and a new one for schemas and a new one for transformation (yes, one could argue XSL could have a much easier syntax if it wasn't XML) - what would be left of XML, then? >... > >Besides the problem of the "rule" element having a gazillion >attributes in the DTD, and the fact that shorthand properties *cannot* >be dropped (they do a lot more than just stand in for other >properties: they also reset related properties in one go), there is >the parsing problem. > >Anybody who honestly believes that the above only requires an XML >parser to parse is strongly mistaken. For example: > > <css:import url="..." media="projection tv"> > >The media attribute needs parsing into space separated keywords. There's nothing wrong with an attribute having complex internal semantics. My application has quite a few. The important part, however, is that it is accessed as a single DOM attribute. Once you start providing access to each sub-part as a separate attribute, with its own name, we start having problems. There's nothing wrong with "media" having a value which is a list of words. > <css:rule pattern="P:first-child + P EM" > >The pattern attribute needs some serious parsing, which cannot >(AFAICT) be spelled out in XML easily (and certainly not as tersely). Actually this could be more XML-ish if it was specified as the equivalent XSL match pattern. Another reason I think XSL is the right place to discuss this issue. For one thing, the match pattern would have to be enhanced by several CSS "pseudo classes". Other then that, as terse as the CSS patterns, and definitely more powrful. >Furthermore, XML does not define how errors should be dealt with, >which is a rather big constraint on future-proofing. CSS has extremely >specific rules for error handling. This is a difference in philosophy. XML is big on validation, CSS on going on and doing something regradless of errors. Each has its merits. In the particular case of mal-formed documents arriving over the net into a browser, I think it can be safely assumed that browsers will do their best to handle it, regardless of which syntax is used. "Go on processing" is a perfectly valid "undefined behavior". >There is also a semantic reason why CSS should not be written in an >XML syntax: XML documents represent trees. CSS does *not* have a tree >structure. It has a structure well designed to _decorate_ such trees. You could say that XSL doesn't have a tree structure; it has a structure designed to _transform_ tree. And so on. The fact is, that almost anything in computer science maps very naturally to trees. This is what makes XML so sucessful. Problems start when you try to handle general graphs. CSS maps very naturally to a tree structure, as deonstrated by the ease of integrating it into the DOM. >Another problem with the concept of using XSL to style documents is that >XSL is not, AFAICT, dynamic (unless you go in with the DOM and directly >change the tree structure, which is quite a drastic thing to do, and >certainly isn't quick and easy). Once the tree has been transformed into a >set of FO elements, you are stuck with that tree, and in particular you >are stuck with that style. With CSS, you can easily change the styles >merely by using the DOM (level 2, currently in draft stage just like XSL >itself). Yes, this a clear advantage of CSS over (FO-based) XSL. This is the major reason FOs will never make it inside browsers. IMVHO, of course. >Personally, I think I will be using XSL mainly to transform the >document so that it contains a structure suitable for formatting. No arguments from me. Now try to convince the XSL WG :-) Share & Enjoy, Oren Ben-Kiki XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format