W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2017

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

From: SelenIT via GitHub <sysbot+gh@w3.org>
Date: Wed, 05 Apr 2017 09:21:18 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-291803839-1491384077-sysbot+gh@w3.org>
> the new rule for :matches() introduces the possibility that different ways of matching a complex selector (i.e., pairings between elements and the compound selectors in the complex selector) have different specificity

@dbaron, could you please provide an example of this possibility?

My understanding so far is that `:matches()` is basically just kind of syntactic sugar for shortening long lists of selectors that have common parts. So, when a browser checks an element against something like `.menu > :matches(a, .current) > .icon`, under the hood it does the same work as for checking the same element against `.menu > a > .icon, .menu > .current > .icon`. Yes, it can possibly introduce performance issues for complex selectors with several `:matches()`, when the browser would have to check the element against all the combinations of their arguments (so the numbers of the variants would multiply), but it still would be in fact just a very long list of the usual selectors, at least one of which is the most specific. Am I wrong?

Also, given that `:matches()` has already [been implemented in WebKit](https://webkit.org/blog/3615/css-selectors-inside-selectors-discover-matches-not-and-nth-child/) for about a year and a half, maybe they can provide some feedback about how they dealt with these issues?

-- 
GitHub Notification of comment by SelenIT
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1027#issuecomment-291803839 using your GitHub account
Received on Wednesday, 5 April 2017 09:21:26 UTC

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