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

Mike Wilson wrote:
>> 2)  How does one define what the "selected subset" is?  Are we 
>>      talking
>>      about "children of the same parent that match the rest of the
>>      selectors in this rule" or something along those lines?  
> I guess I was expecting the subset to be the children that is the
> result of the simple selectors to the left of :nth-child within
> the same sequence, ie "li.item" and "li:not([title])" in these 
> rules:
> > li.item:nth-child(odd)
> > li:not([title]):nth-child(odd)

So li.item:nth-child(odd) and li:nth-child(odd).item would match 
different sets of nodes?  That would be pretty confusing to me as a CSS 
author, and a pretty significant change from how CSS selectors generally 
work right now.

>>      If so, how does this work when multiple :nth-child or 
>>      :nth-of-type selectors are present?  
> Dunno, but my head definitely starts spinning ;-)

Well... this is sort of a key part of the whole thing, no?

>>      It basically seems like this significantly 
>>      complicates
>>      the existing "each chain of simple selectors matches the
>>      intersection of the sets of nodes the individual simple 
>>      selectors
>>      match" model CSS has right now.
> I feel I don't have enough insight in implementations, but I think
> I get your point that this selector couldn't do its job "standalone"
> from the other selectors in the sequence, but would rather be dependent 
> on the result from the selectors to the left of itself, before
> being able to return its own result. Maybe that is a major problem?

It seems like a major problem for _authors_, certainly, the way you've 
defined it.  I don't think it would be that hard to implement, though it 
does mean that certain optimizations have to be thrown out.  But the 
mental model for "how the thing works" becomes very complicated, as you 
noted above with your "head starts spinning" comment...


Received on Monday, 16 March 2009 00:33:58 UTC