Re: CSS-Transformation mechanism and modularizing CSS

> Things like the 'src' attribute of <img> are going to be dealt with by
> the CSS (or at the same time as CSS, if the issues are not yet dealt
> with by a particular CSS spec).
I don't see the src attribute of img as a stylistic feature. In HTML
<img> is meant to contain pictures, which are part of the content, not part
of the style. Currently the <img> element is used a lot for decoration, but
the decoration is going to be part of SVG, where HTML is becoming a way to
describe the content of books, manuals, essays etc.

> In other words, the mapping of
> attributes to rendering is dealt with generically by the style code.
> This has to be the case, because with the exception of a few
> hard-specified attributes such as the XLink attributes, XML documents
> can use whatever they like as attribute names.
I guess you're right here. This makes BECSS also more logical. Do you have a
list of HTML attributes and other visuals (tooltips, window status) which
cannot be set by CSS yet?

> > So the content property seems to apply to all elements in CSS3.
> Yes, but they don't modify the DOM. They just change the rendering.
That's exactly what I mean.
> Remember, CSS does decoration, not transformation.
Decoration is a sort of transformation. You can decorate a cake with such an
enormous amout of whip-cream, that the original cake is unrecognizable.

I was explaining how I would implement CSS. I think the best way is to
create a new tree (or to modify a copy). For the rendering part of a browser
there is no difference between a span element or a :before pseudo-element.
So it makes a nicer implementation if there is a layer between the DOM and
the renderer that creates new inline-elements for :before and :after, and
that replaces the real content with the CSS content.

> > But if you're asking me how to implement this:
> > I'd start with a copy of the DOM tree.
> > To this tree I'd apply the CSS rules, calculating the properties,
> > and creating real element nodes for the pseudo-elements.
> > In this tree I'd also truly apply the content and attribute changes.
> But who is going to look at the attributes of the second tree? The
> `src' attribute, for example, is mapped to generating a replaced
> element at some point during the application of the CSS to the
> original DOM. So including attributes in your second tree will have no
> effect on rendering.
It seems I didn't make myself clear here: the DOM tree represents the
data/content (HTML or XML). Then CSS changes a copy of this tree. The
rendering/presentational part of a browser uses the copy of the tree to
render the document, not the DOM tree.
It really makes sense.

> I do not believe it is the correct way to do
> things (STTS, XSL, and BECSS being the correct ways).
STTS and XSL are more advanced tree transformation tools. CSS is
Transformation Lite (tm). It only adds nodes, or changes end nodes
(content). It does not replace subtrees, sort or delete. This makes it
possible to do realtime 'transformations' from the original DOM tree to the
CSS copy of the tree.

Being dynamical is such a big advantage, even more so when in the future the
browser will not get a new page from the server, but place a Remote
Procedure Call once in a while to change the pages content.

Received on Sunday, 10 October 1999 09:34:31 UTC