W3C home > Mailing lists > Public > www-style@w3.org > September 2003

Re: CSS3 Genrated content, comments/questions

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 15 Sep 2003 14:09:39 +0000 (UTC)
To: "staffan.mahlen@comhem.se" <staffan.mahlen@comhem.se>
Cc: "www-style@w3.org" <www-style@w3.org>
Message-ID: <Pine.LNX.4.58.0309151355250.6502@dhalsim.dreamhost.com>

On Mon, 15 Sep 2003, staffan.mahlen@comhem.se wrote:
>
> http://www.w3.org/TR/css3-content/#nesting
> Can it really be "cost effective" to have nested ::before/::after? It
> seems to me that constructing such elaborate content insertion
> structures makes for to much complexity for the added functionality.
> What does allowing nesting them buy?

It allows varied styling of generated content. It allows constructions
that totally remove all presentational markup from document content -- no
more decorative images, no more duplication of text, no more elements that
are there purely because the CSS needs something to hook onto.


> http://www.w3.org/TR/css3-content/#terminology
> The terminology section has a comment, and to supply my spontaneous
> thoughts i think using the same terms as for the document tree may be
> missleading. If they really must be tree-like, i think using some
> other terminology than ancestor/parent/sibling etc could be useful.
> Something like precursor and/or forerunner perhaps if only upwards
> references are needed?

James Craig suggested 'pseudo-parent', 'pseudo-sibling', and 'preceeding
pseudo-sibling', iirc. I'm not sure if I prefer those terms to the
'superior parent', 'superior sibling', and 'superior' terms, but I think I
prefer them to 'precursor' and 'forerunner'. :-)

And yes, they must be tree-like. The whole point is that these are
elements being inserted into the rendering tree. :-)


> http://www.w3.org/TR/css3-content/#inserting
> Another thing that worried me was the example in which an anonymous
> table-cell was introduced by inserting a ::before content string on a
> table row (as a child of the row i think?). I did not undertand that
> this works the way inserting content into a regular block does, and i
> think complicating the table handing this way may be unnecessary.

It's not really complicating it. You just get all the relevant nodes from
the DOM tree and those nodes' pseudo-elements, then you do the table
construction. Just like being allowed to float or position pseudo-elements
just falls out of most implementations, being able to have them take part
in the table model should be similarly near-automatic.

The main change from CSS2 to CSS3 Content is that ::before and ::after are
promoted from second-class citizens to full nodes with almost the same
rights as real elements. In practice there is little reason not to allow
it.

There are still some things that aren't allowed, for example you can't
apply pseudo-classes to pseudo-elements. Basically, anything that is
typically implemented by hooking into the DOM, such as event-related
changes or bindings, can't be done via pseudos. But everything else
should, IMHO, be fair game, and implementations expecting this shouldn't
find this particularily difficult to implement (at least, not more so than
CSS2 pseudo-elements in the first place).


> Finally, what does the "margin areas" of the applies to fields of
> many properties in gencon refer to?

See the CSS3 Paged Media draft.

   http://www.w3.org/TR/css3-page/

-- 
Ian Hickson                                      )\._.,--....,'``.    fL
U+1047E                                         /,   _.. \   _\  ;`._ ,.
http://index.hixie.ch/                         `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 15 September 2003 10:09:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:23 GMT