RE: CSS and XSL

["Jelks Cabaniss" <jelks@xxxxxxxx>]

Oren Ben-Kiki wrote:

> >> The advantages are:
> >
> >> - Ease of generating CSS from XSL. XSS would be XML, and CSS isn't.
> >
> > Thank goodness.
>
> I assume I missed a smiley here.

No.  You saw the implicit one. :)

> If not, does it mean you think that XML is bad in itself?

Of course not.

I think of XML as the best thing since unsliced bread.  And (on that track) CSS
the best thing since butter, with XTL (potentially) an awesome knife. :)

> I'm also not thrilled by the angle bracket soup, but I'd
> rather have a less then perfect common syntax then a set of three competing
> ones, each with its own particular flaws.
>
> I'm an old fashioned UNIX hacker and fondly remember the days when I could
> do complex operations by combining simple commands using ASCII text files
> (or even better, pipes). I see in XML the potential for providing another
> framework which would allow the same sort of modularity. If we keep styling
> in a separate syntax, then operations manipulating style would be left out.

You're saying that if style isn't expressed in XML, we won't be able to
manipulate it?  Take a look at DOM Level 2, at IE4, at DSSSL.  In fact, wouldn't
the "whole-world-is-XML" approach be more favored by monolithic program
aficionados (you only have to use *one* parser for *everything*) than the Unix
"separate pieces" approach.

And though I'm not necessarily opposed-on-all-counts to expressing style in XML,
I really haven't yet seen an XML approach that doesn't butcher the beauty and
simplistic elegance of CSS.

> >What does "transforming content to structure" mean?  Sounds like
> ASCII-to-Markup
>
> It means I can break my application into three parts. One part handles the
> data model, regardless of any viewing issues. Another is concerned with
> extracting the data to be viewed and reorganizing it to be comprehensible to
> the user. A final part is concerned with the second-to-second dynamic
> styling of the organized data - handling events, highlighting some data,
> collapsing entries in trees, etc.

OK, I see.  One tree (what you called "content") transformed into another tree
("structure"), then that second tree styled.  It's that third part that's got
the masses rioting in the streets.

> Using XSL as it is today, the last two phases are forced into one, which I
> feel is a mistake. Using XML -> XSL -> CSS is better in this regard.

I agree.

> As you
> pointed out, XML+CSS isn't well defined at the moment, and like you I'm not
> aware of anyone who is working on this particular approach.

Not officially, at least that I've seen, but in implementation, IE5b2 does
support:

	1)  The <?xml-stylesheet ...?> PI (= HTML LINK)
	2)  ID and CLASS styling
	3)  Inline CSS (<element style="...">)

of which online the first is "official".

> I tossed this
> idea here as a "heretical view" of how XSL could/should be defined, instead
> of the current FO approach.

No problem with your heresies, but I haven't yet seen a good reason for
recasting CSS as XML, any more than I have seen good reasons for recasting
bitmapped graphic formats or IP packets as XML.  "The-whole-world-is-XML" mantra
does have a certain appeal, but I think it's a rather shallow and myopic one.


/Jelks


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list