Re: CSS-Tranformation mechanism and modularizing CSS

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

Uh... I don't really understand what you exactly mean by "dynamic".

> 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

Yes, I agree that the number of available separators for future css
extensions is _very_ low. And it is true that XMLization would
help. It would also complexify the writing and the reading of
stylesheets. The very big interest of CSS is its simplicity. A rule
can stand on a single line, be understood by a human (I mean a real
one, not ETs like css wg members;-) in a glance, and a CSS parser does
not need a lot of work.

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

Ah. I now understand your 'dynamic' vs. 'static'. Being the
editor/implementor of STTS and one of the editors of BECSS, let me
tell you that your point of view only reflects the actual state of
css-like transformations. More to come in a close future.

By the way, it is extremely easy to define "dynamic" transformations
using BECSS (see W3C drafts list).

> XSL and STTS have to be static, because they
> generate a new document tree. They also have limits

No. STTS do not generate a new document tree at all.

> in XML, because the results need to conform to an
> DTD or Schema.

Again, no. STTS apply to all well-formed fragments/documents too.  The
current implementation of STTS3, which is not public yet, accepts all
flavors of xml docs/fragments, and TIDYzed html docs for instance.

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

I still don't see what is the CSST part of CSS in your mind.  I see
absolutely no transformation capabilities in existing CSS 2, and
that's why my company proposed STTS.

> Well, it was a pleasure to let all my thoughts run free, 
> now please let me now what you think.

You're welcome, and it is a real pleasure to discuss transformations
based on a css-like syntax, but I admit that I have difficulties to
see exactly your point.

</Daniel>

Received on Wednesday, 29 September 1999 03:07:26 UTC