Re: [csswg-drafts] [selectors-4] Rename :matches() to :is()

The CSS Working Group just discussed `Rename :matches() to :is()`, and agreed to the following:

* `RESOLVED: Rename :matches() to :is() and deprecate :matches() in Safari and anywhere else using it`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Rename :matches() to :is()<br>
&lt;dael> github:    https://github.com/w3c/csswg-drafts/issues/3258<br>
&lt;dael> astearns: Added a while back.<br>
&lt;dael> fantasai: One of the side discussions during discussion about :where() was maybe :is is better name then :matches. We have :not and hte opposite is :matches. It being a clear pairing would be useful. Also to make it shorter.<br>
&lt;dael> fantasai: I filed this as a sep issue. We didn't conclude on that tangential discussion. Seems excitement in issue.<br>
&lt;dael> fantasai: We do have Safari shipping :matches() If not that this would be obvious. But there is that. What does WG think?<br>
&lt;dael> leaverou: Given it's only Safari there's no web compat. No body is using this. Personally I'd strongly support. :is is a far better name. It makes a lot of sense. It's the logical opposite of :not<br>
&lt;fantasai> s/be useful/be useful, especially in contrast with :where()/<br>
&lt;dael> astearns: One thing to avoid is having both :matches and :is if it's something where Safari doesn't feel they can rename and have to support both. Both would be a bad result<br>
&lt;dael> smfr: We talked about deprecation path for :matches previously. I'm not sure I"m okay with just switching to :is. I'm sure there will be somewhere using it. But I'm okay with a deprecation path for :matches<br>
&lt;dael> fantasai: Then I propose we rename in spec and Safari sets up a deprecation path. Since you're only impl we'll all have to impl :is. We can not :matches as obsolete and browsers don't have to impl. THen Safari removes at point it makes sense for them<br>
&lt;dael> fantasai: Given it's not in other impl and we don't have web compat clamor to impl matches that seems sensible path<br>
&lt;fantasai> s/can not/can note/<br>
&lt;dael> astearns: Other concerns?<br>
&lt;chrishtr> Tab and I are here, consider backdrop-filter next?<br>
&lt;dael> Bem: I agree no one is using it now but many people have heard of it and there's documentation everywhere. I would piggy back on that instead of renaming it<br>
&lt;dael> s/Bem/Ben<br>
&lt;dael> astearns: bkardell_ mentioned in IRC there's the DOM method called "matches<br>
&lt;dael> fantasai: Sort of. DOM takes a string. DOM doesn't deal with specificity. One of the key distinctions we want and want to make obvious is between :where and this. Calling it :matches doesn't help this distinction. Calling it something not matches means it's not paired to DOM.<br>
&lt;dael> chrisl: I agree with rename to :is. The polyfill argument you can do either way where when polyfills change it will change for them<br>
&lt;dael> leaverou: The polyfills spit out current CSS so no compat issue<br>
&lt;dael> leaverou: Internal compat within CSS is more important than external compat with JS.<br>
&lt;dael> astearns: How one could evaluate is more important. I tend to agree with renaming<br>
&lt;fantasai> fantasai^: Using :is pairs it more closely with :not, which has the same specificity behavior, in contrast with :where<br>
&lt;dael> astearns: Not hearing obj against rename. I propose: Rename :matches() to :is() and deprecate :matches() in Safari and anywhere else using it<br>
&lt;dael> RESOLVED: Rename :matches() to :is() and deprecate :matches() in Safari and anywhere else using it<br>
&lt;dael> bkardell_: I wanted to get clear in my head- That means we're set on :where() for 0 specificity thing.<br>
&lt;dael> fantasai: Yeah. We considered that option and rejected it.<br>
&lt;dael> bkardell_: Okay<br>
&lt;dael> astearns: Anything else on this?<br>
</details>


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

Received on Wednesday, 14 November 2018 17:13:36 UTC