Re: [csswg-drafts] [selectors-4] reconsider specificity rule for :matches()

Attempted to address the clarity issue in 88b91c0486c3f22f59cad547a13545712dbf785f; the specificity rules were written with only compound selectors in mind, and so for complex arguments the existing prose indeed didn't make sense. I don't think it's perfect now, but should be better.

That doesn't address the perf concerns, though. @Loirooriol's comment summarizes some of the options; I'll repeat them here and add the missing one:

- Specificity of `:matches()` is the specificity of the most specific selector that can match. This is what the spec says now, and is the only logical conclusion of treating `:matches()` as syntactic sugar to the extent that it can be (i.e. when it contains compound selectors only).
- Specificity of `:matches()` is the specificity of any other pseudo-class. This is in conflict with how `:not()` works already, and also means that `S:nth-child(n)` and `:nth-child(n of S)` have different specificities, which is imho not reasonable. (They are functionally different, but have the same weight of meaning.)
- Specificity of `:matches()` is zero. Same problems as (0,1,0).
- Specificity of `:matches()` is that of its most specific argument. We lose the equivalency of `:matches(a,b,c)` and `a,b,c`, but we maintain consistency with `:not()`, and `S:nth-child(n)` & `:nth-child(n of S)` maintain equivalent specificities.

GitHub Notification of comment by fantasai
Please view or discuss this issue at using your GitHub account

Received on Monday, 1 January 2018 14:24:39 UTC