Re: CSS-Tranformation mechanism and modularizing CSS

Chris Wilson wrote:
> 
> Sjoerd Visscher [mailto:sjoerd@heeten.nl] wrote:
> >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) 

And which I fought to make normative. Even in its current watered-down
form, though, it has still helped a great deal in resolving discussions;
some sort of processing model is better than none.

> or not, which makes life a lot simpler
> for implementation, 

I recall at the time discussing with you the difference between a model
and an implementation.

> and makes dynamic application considerably more
> possible.

Dynamic application is possible in either model. It is not the presence
of a second in-memory tree that makes XSL slower;it is the presence of
more general selectors (patterns) which can query the entire tree; and
thus, the scope for optimisations (which make the rendering faster) and
progressive display (which makes the rendering seem faster) is greatly
reduced.

Since we agree that an implementation can generate whatever structure it
wants, as long as it has an interface which gives the correct results,
I'm not sure why you are bringing the "that model gives me a slower
implementation" argument out again.


> 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 agree with allof that, except that there are some fairly good tools to
design stylesheets. Not really, really great ones - that take a global
look at your stylesheet and do global optimisation on it, for example -
but still some quite good ones.


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

I agree that that is a limitation of the DOM 2 CSS OM, but it could
readily be added by having a list of pseudos added to the style property
in DOM, and each psuedo has a style property itself.

Or alternatively (and cleaner) one could have in DOM 3 a representation
of the result tree, with pruned subtrees for places where display: none
was set, and extra children that hold the content of :before, :after,
cue-before, cue-after, autonumbers, and suchlike.

Going further, it might be entirely possible to unify this tree with
XSL's internal memory representation of the resuult tree. As I said, its
not the existence of the tree that inhibits tight inner-loop restyling
in real time; its the amount of computation in that loop.

--
Chris

Received on Wednesday, 29 September 1999 19:49:11 UTC