Fw: CSS and XSL

["Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>]

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