[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Fw: CSS and XSL
Jelks Cabaniss <jelks@xxxxxxxx> wrote: > I wrote: >> I feel that the above is a convincing reason to _allow_ an alternative XML >> syntax for CSS (while fully preserving its current semantics!). You don't. > >Actually, that's not the case: I am all for allowing any alternative whatevers >the world can come up with -- alternatives are what makes evolution possible. So we agree after all :-) >I >was merely expressing my personal dislike for the verbosity of what I have so >far seen in *MLized CSS, My suggested XML syntax is slightly more verbose, I admit. But only slightly. >and I remain skeptical of supposed technical benefits >of going that route. That's the real question. As a simple test case, let's take XTL (XSL - FO). Applying XTL to a CSS-annotated XML document can't match on CSS attributes, can't modify CSS stylesheets, and so on. There's even a practically good reason to do such transformations. Consider adapting documents to people with reading disabilities - doing things like replacing the fonts used, or modifying sizes, or colors, and so on. Wouldn't it be nice to express such adaptations/preferences as an XTL sheet which is applied to the "finished" document? >Furthermore, CSS expressed as CSS will be the primary >means of *styling* XML documents in web browsers for at least the next few >years, not XSL. I fully agree. I just think that adding the pointy-bracket alternative syntax, we'd be able to prevent the above fact from enshrining a second syntax in the heart of XML. People would find the current syntax easier? fine, let them use it. XML tools however would find it easier to handle the pointy-bracket one. Conversion between the two would be automatic (I imagine a CSS-to-XSS filter could be added as a SAX filter with no particular difficulty). Maybe that's the answer - define standard CSS-to-XSS and XSS-to-CSS SAX filters. As you pointed out, DOM access doesn't demand point angles, it is parsers that do. Add a PI indicating that such a filter (and in which direction) is recommended when processing this document, and most of the problem would be defused. Now, if only I had a spare week in which to implement this... Have fun, 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
|