RE: CSS-Tranformation mechanism and modularizing CSS

Sjoerd Visscher [mailto:sjoerd@heeten.nl] wrote:
>- CSS and XSL have 2 ways of transforming a document, 
>which are almost complementairy:
>XSLT generates really transforms one XML document into
>another. The most usefull way is to generate a structured 
>and readable document from a (dull and unordered) data source.
>It is therefore more complicated (less straight forward)
>and *static*. It is also a lot more powerfull.
>CSS is dynamic, and very straight forward because it
>just adds properties of elements in an already nicely
>structured document.

Indeed.  In fact, I've argued before that CSS does not actually perform
transformations, only decorations.   I personally think that it needs to be
chosen whether CSS is intended to generate a separate rendering object tree
(the CSS2 spec suggests that it does, in the processing model description
that I fought to make non-normative) or not, which makes life a lot simpler
for implementation, and makes dynamic application considerably more
possible.

>- XML is just a form of defining structured data, 
>and does not imply some kind of functionality to
>it's content.  It's therefore *very wrong* to say 
>that an XML version of (whatever kind of) CSS is 
>similar to XSL. 

XML is in fact irrelevant - it's just a syntax.  That statement makes about
as much sense as saying "ASCII is just a form of defining data, and does not
imply some kind of functionality to its content."  Well, that's true - but
HTML is (usually) ASCII.  The interesting bit is the schema of your XML
content - and in my original response, you should note that I was talking
about the idea expounded on the list, not CSS as it exists today.  I said
"similar to the XML-ized version of your idea", not "similar to CSS
described in XML" (although the XSL-FO stuff isn't that far different).
Perhaps the details of the idea as I filled them in were not the same as you
were thinking, but you don't really contrast CSS above when you say XSL
really does transform one tree to another.  What are you suggesting a "CSS
Transformation mechanism" ought to do if not transform the element tree?

>I think an XML version of CSS is still very attractive.
>Because extending CSS has over time introduced a lot of
>characters with a special meaning, which is starting to
>be confusing. An XML version of CSS will need less
>special characters, because of it's natural way of
>defining structure. (To make my XML version a bit less
>radical, I kept the CSS-selector-style, and in doing
>so even introduced a new special character. That was
>obviously not the best way to XML-ize CSS)

Most of the special characters in CSS are in the selectors, so that really
should be one of the first things to go.  Practically speaking, though, I
personally don't care much about an XML syntax version of CSS as it stands -
it's an interesting exercise, but I don't see a strong need.  A CSS parser
is easy to write, millions of people know the current syntax, there are few
really good tools to design CSS stylesheets so many people use a text editor
and the XML-ization of CSS would be a detriment to their understanding.

>I also want to mention something more about dynamic vs.
>static transformation: CSS (and my suggestions) are
>dynamic, where XSL and STTS are static.

I'll find it interesting to hear more about how you intend to do more than
adornment (e.g. CSS' :before and :after pseudoelements) and pruning (e.g.
CSS' "display:none") in a dynamic way.  How could you re-order elements, for
example, or auto-generate a table of contents?

>XSL and STTS have to be static, because they
>generate a new document tree. They also have limits
>in XML, because the results need to conform to an
>DTD or Schema.

I completely do not understand your second statement here.  They could be
extended like any other schema in the future.

>CSS is dynamic, because it adds attributes (or better:
>properties) to elements on the fly. It does not alter
>the document tree. (That's why the DOM adds all the
>CSS properties not directly to an element, but to the
>style property of an element.)

Considering I wrote the CSS Object Model proposal that grew into the CSS
part of the DOM level 2 drafts, I'm intimately familiar with it, and with
its model.  You don't explain, and the DOM level 2 conveniently skips (e.g.
no representation of :before and :after content or computed properties), how
this dynamic approach could address transformations of any sort.

>CSS has a 'loose' binding of the properties to elements.
>So if we want to make a separate CSST, there has to be
>some way to define that a property may become a real
>attribute of an element. This is critical for properties
>like html:onmouseover.

If all you want to do is control event handlers like mouse overs, then use
the Behavioural Extensions to CSS:
http://www.w3.org/TR/1999/WD-becss-19990804 (draft).

-Chris Wilson

Received on Tuesday, 28 September 1999 19:34:25 UTC