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

The Working Group just discussed `reconsider specificity rule for :matches()`, and agreed to the following:

* `RESOLVED: Make specificity of :not() :has() and :matches() not depend on matching`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: reconsider specificity rule for :matches()<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/1027<br>
&lt;dael> dbaron: I originally filed this, but don't have a strong opinion on decision. Spec needs to be clear on which<br>
&lt;dael> TabAtkins: Other people have argued one direction: :matches() can introduce some thorny issues on selector inheritence. matches specificity is as specific as the most specific branch. More then one :matches with combinators in the branches...you get...you get a combinatorial explosion. You get 100s or 1000s of selectosr without going deep<br>
&lt;dael> TabAtkins: Naive calc is expensive for memory and unbounded costs.<br>
&lt;fantasai> List of options for considerations - https://github.com/w3c/csswg-drafts/issues/1027#issuecomment-354655842<br>
&lt;dael> TabAtkins: Suggestion was don't bother with that. Resolve it the same as :not and :has where it'sspecificity of the most specific branch. So if you put an ID or a tag it'll b e that. THat's straight forward and matches other similar pseudo classes<br>
&lt;dael> TabAtkins: Only problem is that pre-processors doing :matches ahead can only do it with expanding. @extend in SASS will result in a specificity change. It's  not a backwards commpat issue but may be a problem with people or SASS trying to switch to doing the new stuff.<br>
&lt;dael> astearns: [reads dbaron comment]<br>
&lt;dael> TabAtkins: I believe it's correct.<br>
&lt;dael> fantasai: :not takes specificity of most specific arg that didn't match.<br>
&lt;dael> TabAtkins: :not takesa full selector list<br>
&lt;dael> TabAtkins: There's a note. "is replacecd by specificity of most specific element" That note is a liar. That's not true according to spec.<br>
&lt;dael> ??: POinted out a few lies in my comment on the issue<br>
&lt;astearns> s/??/ericwilligers<br>
&lt;dael> TabAtkins: If you look at section 16 :matches and :has uses the brancht hat matches and :not uses the most specific regardless of matching<br>
&lt;fantasai> s/That note is a liar/Also says it has the exact behavior of :not(:matches(argument)), which is a lie./<br>
&lt;dael> frremy: I have another proposal, we  don't allow combintators inside :matches()<br>
&lt;dael> fantasai: We had that for a while. original matches had everything. impl said too complex, we tooki t out, impl then said they want it. So I thinkw e have impl that handle complex selectors<br>
&lt;dael> fantasai: The biggest use case is commas.<br>
&lt;dael> frremy: Commas is the whole point of :match I said combinators<br>
&lt;dael> TabAtkins: Combinators are the difficulty<br>
&lt;dael> frremy: :match without combinators is easy.<br>
&lt;fantasai> i/fantasai: The biggest use case/[some confusion about combinators vs commas]/<br>
&lt;dael> TabAtkins: Without combinators, jsut making it compound, doesn't  simplify. Still have branches. Look at HTML on list bullets. It's a big list. If you do a simple :matches() rule you still h ave combinatorial branching.<br>
&lt;dael> emilio: Removing combinators makes it simplier<br>
&lt;TabAtkins> `:matches(a, #foo) :matches(a, #foo) :matches(a, #foo)` &lt;= naively expands to 8 choices anyway<br>
&lt;TabAtkins> `:matches(a, #foo, .bar) :matches(a, #foo, .bar) :matches(a, #foo, .bar)` &lt;= naively expands to *27* choices anyway<br>
&lt;dael> dbaron: Thing that's still hard is if you leave commas and you can have multiple matches and have you have backtrack to find the right one. As you walk up ancestors you  might match the first on the element and a match for the second with ID but have to try ID ID path<br>
&lt;dael> frremy: Oh, I see<br>
&lt;dael> emilio: Making specificity a property of the selector is nice, i think<br>
&lt;dael> TabAtkins: I see the difficulty and I'm  happy to simplify it<br>
&lt;dael> frremy: I think proposal i s in the right direction.  Easier  to impl i f only compute specificity of the selector as a selector. I can see why people would be confused, but I think it's simplier<br>
&lt;dael> ericwilligers: Same for :not and make it most specific if it matches or not?<br>
&lt;dael> frremy: Yes<br>
&lt;dael> dbaron: I'd be more concerned if I thought specificity was more useful, but I thinik most people fight with it.<br>
&lt;dael> astearns: I'm hearing at least 3 things<br>
&lt;dbaron> s/concerned/concerned with this proposal/<br>
&lt;dael> astearns: 1) places where current spec lies. Need resolutions on those?<br>
&lt;dael> TabAtkins: Won't be a lie once we resolve<br>
&lt;dael> astearns: 2) Removing combinators in :matches()<br>
&lt;dael> TabAtkins: I'd like to keep that separate and reject it.<br>
&lt;TabAtkins> `:matches(.a .b .c, .d .e .f)` expands even faster, of course - expands to over a dozen combination, don't wanna compute the actual number right now because it's non-trivial<br>
&lt;dael> astearns: 3) What we're doing for :matches() and :not(). Is there consensus?<br>
&lt;dael> dbaron: Consesnus to make specificity is only for the selector and not the element<br>
&lt;dbaron> s/only for/only a function of/<br>
&lt;dael> astearns: specificity on :not and :matches depends  on selector and not any possible matching.<br>
&lt;dael> TabAtkins: Should do for has as well<br>
&lt;dbaron> s/for has/for :has()/<br>
&lt;dael> astearns: Do not consider matching when determining specificity of :not :matches and d:has<br>
&lt;dael> ericwilligers: Doesn't know why has needs specificity<br>
&lt;dael> TabAtkins: You can't right now, but in theory an impl could allow it.<br>
&lt;TabAtkins> proposed resolution: :matches() and :has() should only consider their selector arguments (using most specific argument) rather than which branch matched, like :not() currently does.<br>
&lt;dael> astearns: Having a non-testable assertion is annoing<br>
&lt;dael> fantasai: Of course has needs specificity.<br>
&lt;dael> TabAtkins: You can only use it i n JS so specifificty doesn't do anything<br>
&lt;dael> fantasai: but if we ever use it in stylesheet<br>
&lt;dael> TabAtkins: Current spec has an assertion, we should make it accurate.<br>
&lt;TabAtkins> s/accurate/consistent/<br>
&lt;dael> astearns: Objections to making specificity of :not :has and :matches not depend on matching<br>
&lt;dael> RESOLVED: Make specificity of :not() :has() and :matches() not depend on matching<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1027#issuecomment-393236516 using your GitHub account

Received on Wednesday, 30 May 2018 16:58:54 UTC