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

[fantasai]

Breaking this one out from https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-433627117 ; @gibson042 wrote:

@fantasai We may not live in an ideal world, but I think we do live in one that's close enough to introduce :is() and redefine :matches() as a deprecated alias of it. What do you think?

The benefits would be: It's much shorter to type, and it makes a clear pairing with :not(), which is its opposite. The downsides would be: It's already shipping in WebKit as :matches().

Here's the snippet of prior CSSWG discussion, excerpted from the naming of :where():

  frremy: Why use the :matches() name at all, it's a bad name
  leaverou: We're stuck with it anyway
...
  leaverou: Would you object to :is() if it did what :matches()
            currently does, and :match() is the 0 specificity one?
  fantasai: No, I would not
...
  frremy: :matches() was called that way because the DOM API is called that
  fantasai: Actually, it's very old, original :matches() proposal was from hixie
            a long time ago, before :any()
  <dbaron> I implemented :-moz-any() in Gecko in 2010 in
           https://bugzilla.mozilla.org/show_bug.cgi?id=544834
  ericwilligers: It has been in webkit for a long time
  astearns: How much web content uses :matches?
  iank: Not a lot, looking at usecounter
  ericwilligers: usecounter may be wrong

  Rossen: Is either 2 or 7 an option? they involve changing :matches. webkit people,
          can we do that?
  myles: We could
  myles: We would be moderately interested in updating, but it's low priority
  dino: Why ?
  fantasai: Because a well-named proposal otherwise is :is(), but it is bad if
            it's specificity doesn't match :not()
  fantasai: So we could change :matches() to be the 0 specificity one,
            freeing :is() to do what :matches() does now
...
  [subsequently eliminated :matches() from the list of proposals for #2143,
   so this was not further discussed]

I believe other implementations besides WebKit are getting close to shipping :matches() so if we're renaming this, we need to do it asap.

[gibson042]

We both agree that :is() and :not() make a better nonzero-specificity pair than :matches() and :not() and that it would be good to rename :matches() to :is() if possible.

I also make the further claim that even if :matches() cannot be renamed, the semantic value of the :is()+:not() pair is sufficiently high to introduce :is() anyway, and further to recast :matches() as a (deprecated) alias thereof (i.e., :is() as the preferred spelling and the primary entity in documentation).

[inoas]

Deprecating :matches() in favour of :is() is the way to go.

In about 10? years we can talk again about re-using :matches() for something else/with different specificity.

Until then autoprefixers will take care about injecting dupes of :is() as long as there is sufficient user agent base not supporting :is().

[SelenIT]

I agree that, since the WebKit's implementation of :matches() is now not conforming to the changed spec, it would be better to drop :matches() at all (like :any()) and rename this functionality with the improved specificity rules to :is(). But I suppose that after such a change there should be a signal for the vendors that this time the new definition of :is() is really stable and it's safe to implement it. Maybe it's time to defer the less stable Selector features (like :has() and Live/Snapshot "profiles") to Level 5 and make the rest of Level 4 features transition to CR as fast as possible?

Also, is the current implementation of :nth-*-child(... of S) in WebKit conforming to the current spec? Doesn't it currently have the same problem as the implementation of :matches()?

[ExE-Boss]

I am in favour of doing this, the only issue is that according to MDN and Can I use…, this is being implemented and shipping in some browsers.

[ExE-Boss]

Also, before I forget, how about considering :or() instead? (to better match the or operator in programming languages).

[Loirooriol]

@ExE-Boss I think :or() would be confusing, foo:or(bar) seems to mean "foo or bar" to me, i.e. same as foo, bar.

[ewilligers]

I am in favour of doing this, the only issue is that according to MDN and Can I use…, this is being implemented and shipping in some browsers.

We don't need to consider implementations behind a flag or vendor prefix. Only Safari is shipping :matches.

[css-meeting-bot]

The CSS Working Group just discussed Rename :matches() to :is().

The full IRC log of that discussion

<dael> Topic: Rename :matches() to :is()
<dael> github: https://github.com/w3c/csswg-drafts/issues/3258
<dael> ericwilligers: is is now free because a different discussion we had at TPAC. Some people thought that better than matches()
<dael> Rossen_: So drop matches() and replace with is()
<dael> ericwilligers: Or it's a depreciated alias
<dael> Rossen_: Anyone from Safari on the call?
<dael> Rossen_: Doesn't sound like. They're ones effected by change in terms of implementation. We can call for consensus and if anything is raised by webkit folks we can revisit
<dael> florian: We have low attendance. I'm not sure if this is good time to rename things
<dael> Rossen_: Are you saying to could have webcompat issues?
<dael> florian: A bit, maybe
<dael> Rossen_: Also okay to defer to next week
<dael> florian: I support the change, but doing this w/o impl sounds...i don't know
<dael> Rossen_: Does anyone on the call feel strongly about resolving now? If not we'll psotpone
<dael> Rossen_: Let's postpone until next week

[bkardell]

It strikes me that different things appear to be logical depending on which particular things we are looking at the time. The name for some functional "do any of these things match" has taken a lot of twists and turns over the years, for various reasons in various contexts. The DOM APIs today, for example, have matches() which tests whether the element matches any of the selectors. What we are talking about are, kind of pseudos that do that too, so it seems there is some symmetry there as spec'ed today. Maybe that is interesting? In any case, I'm really not sure, and I'm not making any specific case - but given the number of threads on many related things all dealing with naming and desire to flip about - I wonder if It might be somehow worthwhile to consider contexts, history and relationships here?

For example, I've seen what I thought were compelling cases why :any(...) makes sense as the name of the pseudo in CSS, but never a proposal that that would have made a good name in the DOM for something that does kinda the same thing. There, it was pretty much between .matchesSelector, .matches and .is. The first was deemed too verbose in DOM and woudn''t make a lot of sense in CSS. The last makes a lot of sense in CSS but in the DOM, on an element, was potentially problematic.

If we are now talking about 3 things - and one is special in that it has no specificity, perhaps having that thing have close symmetry with the single similar DOM method makes some kind of sense?

[fantasai]

@bkardell I think symmetry with :not() is more important here than symmetry with the DOM method. Note that all of these can be placed inside the DOM method (which is well-named for what it does anyway). Also the DOM method doesn't have specificity either, so making it different is maybe useful? :)

[css-meeting-bot]

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

The full IRC log of that discussion

<dael> Topic: Rename :matches() to :is()
<dael> github: https://github.com/w3c/csswg-drafts/issues/3258
<dael> astearns: Added a while back.
<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.
<dael> fantasai: I filed this as a sep issue. We didn't conclude on that tangential discussion. Seems excitement in issue.
<dael> fantasai: We do have Safari shipping :matches() If not that this would be obvious. But there is that. What does WG think?
<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
<fantasai> s/be useful/be useful, especially in contrast with :where()/
<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
<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
<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
<dael> fantasai: Given it's not in other impl and we don't have web compat clamor to impl matches that seems sensible path
<fantasai> s/can not/can note/
<dael> astearns: Other concerns?
<chrishtr> Tab and I are here, consider backdrop-filter next?
<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
<dael> s/Bem/Ben
<dael> astearns: bkardell_ mentioned in IRC there's the DOM method called "matches
<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.
<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
<dael> leaverou: The polyfills spit out current CSS so no compat issue
<dael> leaverou: Internal compat within CSS is more important than external compat with JS.
<dael> astearns: How one could evaluate is more important. I tend to agree with renaming
<fantasai> fantasai^: Using :is pairs it more closely with :not, which has the same specificity behavior, in contrast with :where
<dael> astearns: Not hearing obj against rename. I propose: Rename :matches() to :is() and deprecate :matches() in Safari and anywhere else using it
<dael> RESOLVED: Rename :matches() to :is() and deprecate :matches() in Safari and anywhere else using it
<dael> bkardell_: I wanted to get clear in my head- That means we're set on :where() for 0 specificity thing.
<dael> fantasai: Yeah. We considered that option and rejected it.
<dael> bkardell_: Okay
<dael> astearns: Anything else on this?

[domenic]

Were any tests updated with this change, or bugs filed against browser implementations? It seems like web platform tests still test for :matches() at the moment (e.g. matches-nested is one of many files in this noisy search that look affected), which makes me wonder how likely browsers are to follow this change.

[ewilligers]

Only four tests (those in css/selectors by Victoria Su) are relevant. I'll update those when I update Blink, as I did (CL1 CL2) for the TPAC rename to :where that made the name :is available.

[hax]

Custom element has added the is attribute, currently there is no specific syntax for is like .class or #id. If no other background, I worry about that devs could be confused what a:is(b) mean (select <a is=b>?)

[yisibl]

@ewilligers When is Chrome planning to fully implement Selector Level 4?

[ewilligers]

@ewilligers When is Chrome planning to fully implement Selector Level 4?

The semantics for :is() and :where() may stabilize this month, when https://github.com/w3c/csswg-drafts/issues/3264 is decided. I had not anticipated that their names and semantics would take a year to stabilize.

Chrome should be able to ship :is() and :where() in Q2 2019 (with WPTs this quarter). These are first priority as people currently use :-webkit-any(). :not() and nth-child() and nth-last-child() with general selector lists should be able to ship at the same time.

There are are variety of open issues for Selectors Level 4; I decline to estimate when they will be resolved, and when the various new features will ship.