- From: fantasai via GitHub <sysbot+gh@w3.org>
- Date: Mon, 01 Jan 2018 14:24:37 +0000
- To: public-css-archive@w3.org
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 https://github.com/w3c/csswg-drafts/issues/1027#issuecomment-354605655 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 https://github.com/w3c/csswg-drafts/issues/1027#issuecomment-354655842 using your GitHub account
Received on Monday, 1 January 2018 14:24:39 UTC