RE: [css3-selectors] structural child indexes vs rule selections

Brad Kemper wrote on 14 mars 2009 18:05:
> It seems to me that would be a different feature. If you are basing  
> the index on what is selected, instead of the DOM, then the items  
> would not even need to be siblings in the DOM. You could call 
> it 'nth-item' perhaps. As a new feature, it would not be included 
> in Last Call changes, but could be a good future addition.

Interesting, there are many variations on this theme :-) More below.

Andrew Fedoniouk wrote on 14 mars 2009 18:16:
> That will not work, sorry. Selector
> 
>    li.item:nth-child(odd)
> 
> would require scanning of the whole DOM tree
> in order to resolve the style.
> 
> Think about multiple lists in your document.
> To be able to find style for particular LI you
> would need to scan all lists.
> 
> And if you will say dynamically add the item in one of them
> all other li.item in the DOM need to be recalculated.

It seems we are talking about three different models here:
- child indexes based on an element's position in its parent's
  child list irrespective of selection [CSS 3 spec]
- child indexes based on an element's position in the selected
  subset of its parent's child list [Mike]
- child indexes bases on an element's position in the total
  query result from all parents [Brad and Andrew]

I fully agree there are more performance hits the further down
you go on this list. I was thinking about the middle case as I
wanted :first to trigger in every child lists - with the third
model it would only trigger in the first list, right?
(And please excuse me if I have interpreted anything wrong here)

When bringing this question up I was mainly curious on what was the
main drivers for the specified behaviour; perceived correctness, 
performance, etc?

When looking at f ex the "of-type" selectors I get the impression
that there are actually desires to handle different sets of child 
indexes, with the natural performance implications:

  div > *:first-child {color:red;}
  div > p:first-of-type {font-weight:bold;}
  <div>                   // -child | -type(span) | -type(p)
    <span>a</span>        //  1        1(red)
    <p>b</p>              //  2                      1(bold)
    <span>c</span>        //  3        2
    <p class="para">d</p> //  4                      2
  </div>

In the above the engine will be handling several sets of child
indexes to cater for different selection needs. I see it as 
somewhat awkward that the pseudo class name is used to signify
what parts of the existing selector will be used to base child
indexes on (first-child will consider nothing, first-of-type
will consider the preceeding selector's element type). 

Extending this model would mean inventing a new pseudo class for 
every combination of selectors to consider for indexes. 
To f ex match the first <p> with class "para" (4th child above), 
we would need:

  p.para:first-of-type-and-class

and from there it is an open road to:

  .item:first-of-class
  a.secret[rel]:first-of-type-and-class-and-attr
  ... etc ...

Ok, this may be a bit silly but my main point is that we here
have pseudo classes that make their own assumptions about 
selection dimensions that really belong to other selectors. It
would be more orthogonal if these choices were made by reusing
the existing selector syntax.

Best regards
Mike Wilson

> On Mar 14, 2009, at 6:44 AM, "Mike Wilson" 
> <mikewse@hotmail.com> wrote:
> 
> > Pardon me if this have been covered before, but has there been
> > any discussion on whether :nth-child (and other structural
> > selectors) should be able to work on indexes from the selected
> > child subset rather than from the 'complete' child list?
> >
> > Example targeting all <li>s:
> >  li.item:nth-child(odd) {background-color:grey;}
> >  <li class="item">a</li>  --> index 1 = odd = grey
> >  <li class="item">b</li>  --> index 2 = even
> >  <li class="item">c</li>  --> index 3 = odd = grey
> >
> > Example targeting subset of <li>s:
> >  li.item:nth-child(odd) {background-color:grey;}
> >  <li>...</li>             --> index 1 (not selected)
> >  <li class="item">a</li>  --> index 2 = even
> >  <li class="item">b</li>  --> index 3 = odd = grey
> >  <li class="item">c</li>  --> index 4 = even
> >
> > In the second example we see that the first <li> "consumes"
> > the first odd entry from the formating rule, although it is
> > not selected by this rule. This makes the whole striped
> > formating visually shift one step forward as a side effect of
> > introducing an element not covered by the rule.
> >
> > Would it be desirable to instead count indexes based on
> > the selected subset, like in:
> >  li.item:nth-child(odd) {background-color:grey;}
> >  <li>...</li>             --> (not selected)
> >  <li class="item">a</li>  --> index 1 = odd = grey
> >  <li class="item">b</li>  --> index 2 = even
> >  <li class="item">c</li>  --> index 3 = odd = grey
> > ?
> >
> > Best regards
> > Mike Wilson

Received on Sunday, 15 March 2009 11:17:06 UTC