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