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

Boris Zbarsky wrote on 16 mars 2009 01:33:
> Mike Wilson wrote:
> > 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
> 
> 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.

That is a valid point, but the behaviour chosen here doesn't really
affect the "core" of what I am seeking. If disregarding current
principles I guess I could see advantages with both models. Letting
them match the same nodes has the advantage of simplicity, but having
them behave differently adds expressiveness, f ex:

  <li class="foo">a</li>
  <li class="foo">b</li>
  <li class="foo">c</li>
  <li class="item">d</li>
  <li class="item">e</li>
  <li class="item">f</li>
  li.item:nth-child(odd) -> d, f
  li:nth-child(odd).item -> e

Personally I don't find this confusing as an author, but I fully 
respect that others would. Again, this is not the core of my 
proposal and it could be done either way.

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

I'm not sure if I regard stacking multiple :nth-child on each
other to be the key part of the whole thing, but certainly there
is need for a coherent model. My "spinning head" reply was given
to say that people more knowledgeable than me in these areas
could chime in and say how it should best work. I'm sorry that
this didn't get through.

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

Again, the "left only" part of the equation isn't crucial. Though,
really nth-of-type() does just this already (looks at the selector to
its left):

  p:nth-of-type(odd)

nth-of-type can't do its job without looking at the type selector, and
then run its own query (whether this is done by reusing the 
result/subset from the type selector, or running that query an extra 
time, is up to implementations I guess?).
Of course there is no ambiguity for nth-of-type as the type selector
can only appear at the start of the sequence and is thus always to the 
left.

Tab Atkins Jr. wrote on 16 mars 2009 03:20:
> On Sun, Mar 15, 2009 at 7:33 PM, Boris Zbarsky 
> > 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.
> 
> This ambiguity can be cleared up by explicitly specifying the subgroup
> you're wanting to target.
> 
> In the OP, Mike wants to grab just the <li class="item">, and then
> style the odd ones, ignoring any <li>s with another class. 

Thanks for returning to the core subject here!

> A syntax like this would make it explicit:
> 
> li:nth-match(odd, .item)
> 
> This would first grab all the <li>s, then specialize onto only those
> with class="item" to number, so that the "odd" specifier only cares
> about <li class="item"> elements.

Yes, this is the kind of syntax that was lurking in my head as well,
adding an explicit "subset" selector inside our selector.
It also adds the extra expressiveness I mentioned above (there 
controlled by "left and right") and the two selectors below will return
different sets:

  <li class="foo">a</li>
  <li class="foo">b</li>
  <li class="foo">c</li>
  <li class="item">d</li>
  <li class="item">e</li>
  <li class="item">f</li>
  li:nth-match(odd, li.item) -> d, f
  li:nth-match(odd, li).item -> e

A small downside is that many times this syntax will just force the 
author to repeat or move the selector to the inside but that's 
probably a price that is ok to pay. The three selectors below would be 
identical: 

  li.item:nth-match(odd, li.item)
  li:nth-match(odd, li.item)
  *:nth-match(odd, li.item)

I don't know if it is interesting to also have a selector that uses
index in selection subset without regard to parent (the way you and
Andrew first understood my suggestion), but if it is then the naming
might be:
  :nth-match(x, selector)       // uses full subset
  :nth-child-match(x, selector) // uses parent subset

Thanks for taking the time to discuss this!

Best regards
Mike

Received on Monday, 16 March 2009 11:15:40 UTC