[selectors-4] Defer complex selectors inside :nth-child() etc. to L5

[fantasai]

At the F2F we briefly discussed deferring combinators inside :nth-child() etc. to a future level of Selectors, to make it easier for us to get implementations and interop on the more critical featureset. However, we didn't resolve on the issue. Do we want to do this?

[...]
fantasai: I think it would make more sense with compound, not complex selectors
fantasai: The big question for :nth-child() was compound vs complex selectors.
fantasai: people want :nth-child(An+B of )
fantasai: If dropping support for combinators makes it easier, would be good to get it implemented faster. Things like zebra-striping non-hidden rows is a major use case that's not currently solved otherwise.
ewilligers: I think webkit already shipped complex selectors in :nth-child()
dydz: I'm looking in the WK code

fantasai: Emilio asked why we need selectors in :nth-child()
fantasai: Say we have a list of items, I want to color their backgrounds alternately
fantasai: But some of them are hidden; they're display:none
fantasai: Counting is based on sibling list. If you hide 3rd one,
2nd and 4th will both have the same color
fantasai: So want to count after filtering
emilio: Whew, that's gonna be slow. We have a lot of caching already to make :nth-of-type() fast.

ewilligers: I confirmed that Safari supports :nth-child(even of div+div)
fantasai: My main concern is if other impls are more likely to implement without complex selectors, getting even compound-selector interop would still be great.
emilio: I think impl-wise, not supporting complex selectors is easier.
TabAtkins: Unless we recursively pass down the compound-only restriction into :is()/etc, you're at full power anyway.
fantasai: Maybe that's reasonable to have that sort of restriction.
fantasai: We'll just say Safari supports L5 of selectors, and L4 doesn't accept combinators
agreed. reasonable restriction

Possible proposals:

• Don't do this
• Do this only for :nth-child() and :nth-of-type()
• Also do this for :is()/:where()/:not()/:has()

[ewilligers]

For :is()/:where()/:not()/:has(), I made some Blink implementation progress in early January but have since focused on non-CSS work.

I haven't yet looked at :nth-child() / :nth-last-child().

[css-meeting-bot]

The CSS Working Group just discussed Defer complex selectors inside :nth-child() etc. to L5, and agreed to the following:

• RESOLVED: Defer complex selectors for all of these selectors and have a note in the current level mentioning this is an enhancement we'll get to in the next level

The full IRC log of that discussion

<dael> Topic: Defer complex selectors inside :nth-child() etc. to L5
<dael> github: https://github.com//issues/3760
<astearns> fantasai: These selectors have been highly requested for years. We know that WK had impl the full functionality allowing combinators and everything but no one else has impl. There is a question of should we reduce scope of L4
<dael> fantasai: Question I wanted to ask is do we take this back to only allow compound for now and add complex in the future to make impl easier or is that not relevant concern?
<dael> fantasai: Interop of reduced subset solves most of the problems
<dael> AmeliaBR: No one would ask WK to rollback it's jsut defer to next level?
<dael> fantasai: Yes
<dael> astearns: Concerns from WK?
<dael> smfr: I think we're okay moving those bits to next level
<dael> astearns: IN issue question of how many selectors we defer complex selectors for.
<dael> astearns: Question is do we defer complex for :nth or also the is/where/not/has collection?
<dael> myles: For specs to get to rec we need two impl so why not start there?
<dael> astearns: With eerything?
<dael> myles: If not 2 impl and no plan for another one...
<dael> myles: We have to defer
<dael> myles: Sooner or later
<dael> fantasai: I don't want to have someone not impl and push off impl of these features in general because doing all at once is too much.If reducing size gets us an impl fast that's good.
<dael> fantasai: I want to hear from Gecko and Blink are you planning to impl and if yes would trimming make it faster
<dbaron> can you hear me?
<dael> TabAtkins: I have to ask, I'm not certain. WE're not against it but I don't know scheduling
<dbaron> stupid webex
<dael> AmeliaBR: Comment in issue from eric W that he started but hasn't worked recently
<dael> emilio: We don't have immediate plans to impl, but complex selectors really complicate getting invalidation right so it would definitely take more if we had to figure out combinators
<dbaron> So webex doesn't appear to be letting me rejoin, so I'll write my comment in IRC
<dael> fantasai: Is that true for the nths oly or also is/where/not
<dael> emilio: If we solve we have to do for all at once
<dbaron> oh, back in
<dael> fantasai: That seems like a good arguement to refer to next level if can get Gecko impl sooner
<dael> dbaron: I think if the result you want is finding out...is A encouraging impl and B finding out if extra parts will cause pain I think perhaps best way is add a note ot spec that says we're considering dropping. If they make your impl harder please impl without and let us know. Because then there's clear intent WG is interested in feature as a whole but also just those parts
<dael> fantasai: COuld do opposite and just add subset and note we're doing the rest in L5 and these already impl in WK but seemed too complex for others
<dael> florian: That's harder editorially. Do you think subset is easy to figure out in reading spec? Or is note saying can do subset is enough so don't have to editorially split it up
<dael> fantasai: If we're doing it for all at once it's quite simple editorially.
<dael> astearns: For myself it would be clearer reading spec to have complex selectors broken to next level with a note saying intend to add in future level. It's easy to look at production with complex selectors and miss the note and think it's too much
<dael> astearns: My preference is to defer complex selectors for all of these and have a note in the current level mentioning this is an enhancement we'll get to in the next level
<dael> astearns: Objections?
<dael> RESOLVED: Defer complex selectors for all of these selectors and have a note in the current level mentioning this is an enhancement we'll get to in the next level

[fantasai]

I committed the changes for this only for :nth-child() and :nth-last-child() since multiple browsers seem to already implement complex selectors for :is()/:not()/:where() already...

[fantasai]

Agenda+ to confirm whether we want to leave complex selectors in for :is()/:not()/:where() for Level 4 and only compound selectors for :nth-child()/:nth-last-child() or if we want to do something different (like allow complex selectors everywhere).

[Loirooriol]

So in L4 :nth-child(1 of .foo+.bar) is invalid, but :nth-child(1 of :is(.foo+.bar)) is valid?

[css-meeting-bot]

The CSS Working Group just discussed [selectors-4] Defer complex selectors inside :nth-child() etc. to L5, and agreed to the following:

• RESOLVED: Revert the resolution from #3760, removing the "no complex selectors" restriction from :nth-child()

The full IRC log of that discussion

<fantasai> Topic: [selectors-4] Defer complex selectors inside :nth-child() etc. to L5
<fantasai> github: https://github.com//issues/3760#issuecomment-1119234126
<fantasai> scribenick: TabAtkins
<TabAtkins> fantasai: We had agreed to defer complex selector sinside :nth-child() until levle 5
<TabAtkins> fantasai: and :is() and :where(), etc
<TabAtkins> fantasai: It seems like it's been implemented in :is()/:where()/:not() tho
<TabAtkins> fantasai: So I committed the edits to restrict it for :nth-child()/etc, but not for the others that have already implemented it.
<TabAtkins> fantasai: So I want to know if we really do want this restriction for :nth-child(), or if impls are okay with just allowing complex selectors.
<TabAtkins> fantasai: Oriol had a question about nesting :nth-child(... of :is()), the restriction would be recursive.
<TabAtkins> astearns: So both those examples would b einvalid?
<TabAtkins> fantasai: Yes.
<TabAtkins> fantasai: Or both valid, depending.
<TabAtkins> fantasai: So question is, what do impls want to do?
<TabAtkins> emilio: Since Blink and Gecko don't yet implement the "of <selector>" at all yet, I'd be okay with moving it to level 5. But we should implement it.
<TabAtkins> fantasai: Note that this just about complex selectors in "of <selector>"
<TabAtkins> fantasai: Not the general feature
<TabAtkins> fantasai: so :nth-child(1 of .foo) would be valid in level 4, but :nth-child(1 of .foo .bar) would be invalid
<TabAtkins> emilio: Don't think it matters much either way. When we get to implement it we'll probably do the ocmplex selector form.
<bkardell_> +1 to move it to level 5
<TabAtkins> emilio: Guess it matters how much it matters for Selectors 4 to have multiple interoperable impls, but we don't implement the simple selector syntax either in Gecko.
<TabAtkins> fantasai: Opinions from the Safari team?
<TabAtkins> jensimmons: I think we've already implemented it
<TabAtkins> TabAtkins: I know Safari has done at least simple selectors, dunno about complex
<fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3Ep%3Anth-child(1%20of%20body%20%3E%20p)%20%7B%20background%3A%20yellow%3B%20%7D%3C%2Fstyle%3E%0A%0A%3Cp%3Estylethis
<TabAtkins> astearns: In terms of spec advancement, punting complex selectors means we could promote level 4 as soon as simple selectors are done by multiple impls. But it's not clear to me if that's actually going to happen.
<TabAtkins> fantasai: It seems like webkit supports complex selectors in :nth-child()
<astearns> s/actually going to happen/actually going to happen before complex is also supported/
<TabAtkins> fantasai: So question is just to other impls - do you want to tackle complex selectors when you do the feature at all? Or do it stepwise?
<TabAtkins> futhark: Don't have thoughts about it right now.
<TabAtkins> emilio: Same
<TabAtkins> emilio: I don't see anything terrible complicated about supporting complex selectors.
<TabAtkins> emilio: Might make the invalidation a little trickier, but probably not by much.
<TabAtkins> fantasai: Okay so if we don't know, and Safari has already done it, I suggest we remove the restriction.
<bkardell_> ok
<TabAtkins> fantasai: If we need toa dd the restriction later we can do that.
<TabAtkins> emilio: Sounds good.
<TabAtkins> astearns: so proposed resolution is to undo the previous resolution and put complex selectors back into :nth-child(), until we see that this is a blocker for level 4 advancement
<TabAtkins> astearns: Objections to reversing the previous resolution?
<TabAtkins> (in issue 3760)
<TabAtkins> chrishtr: Rune can you confirm if this is implemented this way in Chrome at th emoment?
<TabAtkins> futhark: We don't implement the "of <selector>" at all in Chrome yet
<fantasai> TabAtkins: Right now everyone supports :th-child(), only safari supports :nth-child-(.. of selector)
<fantasai> TabAtkins: we have a resolution the books to restrict that selector to compound selectors
<fantasai> TabAtkins: we're reversing that resolution
<TabAtkins> chrishtr: So that won't have any effect on chromium and gecko shipping :has(), and forward compatible with us shiping the upgraded :nth-child() in the future
<TabAtkins> TabAtkins: yeah
<TabAtkins> chrishtr: So this is kinda just a technicality?
<TabAtkins> astearns: Yeah just level wrangling
<TabAtkins> astearns: Either we get a second impl of this in :nth-child(), or we get really close with everything else in level 4 and we defer *all* of the :nth-child() enhancements to advacne the spec
<TabAtkins> emilio: Or we get a second impl but that only did simple selectors, we could punt the complex selectors again. But doesn't matter much for impls right now.
<TabAtkins> chrishtr: Sounds fine, doesn't affect our current impl plans.
<TabAtkins> astearns: So, any objections?
<TabAtkins> RESOLVED: Revert the resolution from #3760, removing the "no complex selectors" restriction from :nth-child()