W3C home > Mailing lists > Public > public-css-archive@w3.org > January 2018

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

From: fantasai via GitHub <sysbot+gh@w3.org>
Date: Mon, 01 Jan 2018 14:24:37 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-354655842-1514816676-sysbot+gh@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

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:22 UTC