New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

fantasai opened this Issue Oct 27, 2018 · 8 comments


None yet
8 participants

fantasai commented Oct 27, 2018

Breaking this one out from #2143 (comment) ; @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
  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.


This comment has been minimized.

gibson042 commented Oct 27, 2018

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).


This comment has been minimized.

inoas commented Oct 28, 2018

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().


This comment has been minimized.


SelenIT commented Oct 29, 2018

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()?


This comment has been minimized.

ExE-Boss commented Nov 1, 2018

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.


This comment has been minimized.

ExE-Boss commented Nov 2, 2018

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


This comment has been minimized.


Loirooriol commented Nov 2, 2018

@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.


This comment has been minimized.


ewilligers commented Nov 7, 2018

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.


This comment has been minimized.


css-meeting-bot commented Nov 8, 2018

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:
<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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment