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

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

From: L. David Baron via GitHub <sysbot+gh@w3.org>
Date: Sat, 11 Feb 2017 20:40:12 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-207006726-1486845611-sysbot+gh@w3.org>
dbaron has just created a new issue for 
https://github.com/w3c/csswg-drafts:

== [selectors-44] reconsider specificity rule for :matches() ==
The [rules on 
specificity](https://drafts.csswg.org/selectors-4/#specificity-rules) 
in selectors-4 say:
>  The specificity of a :matches() pseudo-class is replaced by the 
specificity of its selector list argument. (The full selector’s 
specificity is equivalent to expanding out all the combinations in 
full, without :matches().) 

I just realized two things:
1. this isn't worded in a particularly clear way
2. I'm actually someone nervous about the performance implications of 
the only logical way to make it clearer.

What is unclear, I think, is that the concept of specificity of a 
selector list requires both a selector list *and* an element being 
matched, since it uses the highest specificity form *that matches the 
element*.  The algorithm doesn't make it clear that the element being 
matched is passed to the algorithm.

But that, in turn, pointed out to me that since `:matches()` can 
appear anywhere in a selector (between combinators), there might be 
multiple elements that could match a given matches.  In order to not 
expose the *order* in which an implementation searches the subtree to 
find the set of elements that match the combinators, the specification
 also needs to require that the specificity of a complex selector be 
the highest-specificity way of matching that complex selector.  This 
is because 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.

This, in turn, requires changes to how implementations match 
combinators, so that they search the tree for the highest-specificity 
way.  I believe this may have substantive performance implications for
 at least some combinations of combinators, although I haven't 
actually worked the problem through yet.  Somebody should!

This, in turn, makes me wonder whether we should reconsider whether 
the new specificity rule for `:matches()` is actually a good idea.  
(Another option is marking it at risk, but that has its own problems.)

If we do keep it, I'd like to ensure we add tests that exercise the 
performance-sensitive cases.

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/1027 using your GitHub 
account
Received on Saturday, 11 February 2017 20:40:51 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 19 October 2021 01:30:29 UTC