|
[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
|

Cart








