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