w3c is iffy on complex vs compound in nth-child and possibly other lists

I’m not sure if this will affect us, but I figure I’ll create an issue to track this. It seems that there was some concern with whether :nth-child(an+b of) should support compound or complex selectors. The idea is that it may be easier to get compound out the door first for L4, and then complex would be deferred to L5. The discussion seems to question others as well such as :is(), :not(), etc.

If they defer to L5, I don’t think anything for us will change. If that is the case, we’ll just say we support L5. If they completely abandon complex in one or more, we may have to downgrade complex support to compound.

[facelessuser]

No browser supports it, I think it’s not worth exploring. At least that’s what I decided.

Agreed.

./**/foo

Ugh, I think I generally do pretty good at allowing comments, but yeah, I don’t support that. I think I only allow them in cases where whitespace is acceptable, which is like 99% of the cases, but apparently not all of them 🙂 .

Yeah, if you have to parse all valid CSS, which it sounds like you do, you have to look for that kind of stuff and have a finer resolution of how you tokenize. In my case, I’m close enough to be usable for the cases of my users.

[facelessuser]

This conversation reminded me that the documentation for this has already been updated mentioning our current direction. We mention the differences between level 3 and level 4 and mention that we follow the discussed level 5 direction. This issue can actually be closed as all of this is now addressed.

I think even if the CSSWG were to completely drop complex selectors, we might keep them around in Soup Sieve simply for their usefulness. While we strive to follow the spec, we are not completely bound to it as we allow for things like :contains() etc.