Re: CSS3 Genrated content, comments/questions

On 15 Sep 2003 at 14:09, Ian Hickson wrote:

> > http://www.w3.org/TR/css3-content/#nesting
> > Can it really be "cost effective" to have nested ::before/::after?
> > ...
> 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.

When are nested before/after needed for this and a single 
::before/::after not adequate?

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

I did not realise that inserting a string between inside table 
elements should create the anonymous table cell in the current table 
model. 

This is an area where browsers are not generous in what they accept, 
and i think for good reasons. With ::before the string gets inserted 
as if it was the first-child of the tr, but just in case i tried 
between tr:s as well.
    <p>String between tr td:</p>
    <table>
      <tr><td>First</td><td>Second</td></tr>
      <tr>Third<td>Fourth</td></tr>
    </table>
    <p>String between tr /tr:</p>
    <table>
      <tr><td>First</td><td>Second</td></tr>
      Third
      <tr><td>Fourth</td></tr>
    </table>

While the above is obvisouly invalid, i don't see that browsers 
currently try to recover by treating the strings as if they were 
cells, and i am not quite sure they should either. 

I think this may be a misstake in the CSS table model, it would be 
better to require more from the author here. That is, each internal 
table element should required to be declared as such, and error 
recovery as defined in CSS 2.1 seems to me like it is to error prone 
(excepting the case where a single block is defined as table-cell, 
which usually indicates a hack anyway?).

As a side note, does a CDATA node count as a table element or is it 
the pseudo-element that is considered the table element? (not that it 
matters in todays browsers who wont default to cell anyway).

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

Hmm, very interesting but also yet another area i dont quite get. 
Just for the sake of clarity, when you say first class citizens and 
nodes you are not suggesting that for instance scripting will be 
allowed to use regular DOM methods to access the the nested pseudo-
elements right? (eg firstChild will never be a pseudo-element).

If so, will the DOM style rec be modified to allow accessing those 
nested pseudo elements or should they only be available using the 
generic methods? While i don't really use scripting myself i think it 
may introduce issues for generic scripts. For each node you work 
with, it seems you also need to consider the style of all nested 
::befores and ::afters if you wish to work with every visible item?

I still think some quite important use cases are needed for nesting 
to be worthwhile.

 /Staffan

Received on Tuesday, 16 September 2003 08:29:20 UTC