[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Fw: CSS and XSL

Subject: Fw: CSS and XSL
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Wed, 3 Mar 1999 13:20:16 +0200
applying css to 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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.