- From: Chris Lilley <chris@w3.org>
- Date: Sun, 10 Oct 1999 16:54:27 +0200
- To: Sjoerd Visscher <sjoerd@heeten.nl>
- CC: www-style <www-style@w3.org>
Sjoerd Visscher wrote:
> > > 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.
Right.
One thing that we seem to be lacking is a way to say precisely, in the
CSS stylesheet, what renderer will be used for a particular subtree. In
general, the CSS renderer will be used - one that does box-based,
constraint-based layout. But in some cases (SVG; MathML) and arguably in
others (inline PNG, inline JPEG, etc) there is a different renderer.
By identifying the renderer I do not mean, a pointer to a piece of code
which will execute on a particular platform. Thats what plugins do, and
that is why plugins are a poor solution (the number of platforms is
increasing). Rather, a declarative symbol which indicates - "this is
MathML" or whatever.
This is what "svg {display:svg}" was intended to convey. For some
purposes, such as for generating a text-only display or for aural
presentation, SVG might be rendered using the normal CSS renderer (so
one would have, svg { display: block} ) since the content of SVG is
text.
I notice that the ICE browser [1] uses this concept of different
renderers working on the attributed tree; and so does the Mnemonic [2]
browser.
It's interesting that both of these do XML and CSS, and either do or
intend to do MathML.
> > 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.
OK, true. CSS does not do general transformation. Then again, neither
does XSL-T.
> 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.
I have to say that I completely agree with this assesment, whilst also
recognising that other implementation strategies are possible (and that
these might have drawbacks such as difficulty with :first-line and :
first-letter).
> > > 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.
Yes.
> > But who is going to look at the attributes of the second tree?
The renderer.
> > 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.
Not necessarily, though they may be quite different attributes from
those in the source trree (see for example using full XSL, where the FO
tree has very different attributes which do, indeed, affect the
rendering).
Given that selectors (or XSL patterns) work on the source tree and that
the DOm gives a view of the source tree, the concept of a separate
rendering tree is still a valuable device for modelling and also for
implementation.
> 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.
Yes.
> 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.
Again, I have to agree here.
> > I do not believe it is the correct way to do
> > things (STTS, XSL, and BECSS being the correct ways).
I think that here, the two previous authors are talking at cross
purposes; both are right, but they are not talking about exactly the
same thing.
> STTS and XSL are more advanced tree transformation tools. CSS is
> Transformation Lite (tm). It only adds nodes, or changes end nodes
> (content).
It also removes nodes (display: none)
> It does not replace subtrees, sort or delete.
Agree about the first two.
> This makes it
> possible to do realtime 'transformations' from the original DOM tree to the
> CSS copy of the tree.
Yes. This is one difference from XSL, where dynamic alternatives are
pre-generated in the result tree and switched between.
> 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.
I agree that, especially for dynamically created content, suich as
streaming or timed updates from a server, a fast and dynamic cascade is
likely to be a better bet than static creation of switchable alternates.
For cases which are known in advance (such as 90% of Javascript
rollovers for example) the XSL approach of switchable alternatives is
certainly useful, however.
--
Chris
[1] http://www.icesoft.no/
[2] http://www.mnemonic.org/
Received on Sunday, 10 October 1999 10:54:43 UTC