Skip to content
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

Closed
fantasai opened this issue Oct 27, 2018 · 16 comments
Closed

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

fantasai opened this issue Oct 27, 2018 · 16 comments

Comments

@fantasai
Copy link
Collaborator

@fantasai 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
           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
Copy link

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

@inoas
Copy link

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

@SelenIT
Copy link
Collaborator

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

@ExE-Boss
Copy link
Contributor

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

@ExE-Boss
Copy link
Contributor

@ExE-Boss ExE-Boss commented Nov 2, 2018

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

@Loirooriol
Copy link
Collaborator

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

@ewilligers
Copy link
Contributor

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

@css-meeting-bot
Copy link
Member

@css-meeting-bot 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: https://github.com//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
Copy link
Contributor

@bkardell bkardell commented Nov 13, 2018

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
Copy link
Collaborator Author

@fantasai fantasai commented Nov 14, 2018

@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
Copy link
Member

@css-meeting-bot css-meeting-bot commented Nov 14, 2018

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//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?
ewilligers pushed a commit to ewilligers/csswg-drafts that referenced this issue Nov 14, 2018
The functional pseudo-class like :where() but with specificity
is named :is() instead of :matches().
w3c#3258 (comment)

resolves w3c#3258
@fantasai fantasai closed this Nov 14, 2018
@domenic
Copy link
Collaborator

@domenic domenic commented Nov 15, 2018

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
Copy link
Contributor

@ewilligers ewilligers commented Nov 15, 2018

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.

chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Nov 15, 2018
Recent CSS WG decision
w3c/csswg-drafts#3258

Bug: 568705
Change-Id: If24be4b2c0a49ba12c92df873b0a4de12eb1a21e
chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Nov 15, 2018
Recent CSS WG decision
w3c/csswg-drafts#3258

Bug: 568705
Change-Id: If24be4b2c0a49ba12c92df873b0a4de12eb1a21e
@hax
Copy link
Member

@hax hax commented Nov 15, 2018

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
Copy link

@yisibl yisibl commented Nov 15, 2018

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

@ewilligers
Copy link
Contributor

@ewilligers ewilligers commented Nov 15, 2018

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

The semantics for :is() and :where() may stabilize this month, when #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.

chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Nov 16, 2018
Recent CSS WG decision
w3c/csswg-drafts#3258

Bug: 568705
Change-Id: If24be4b2c0a49ba12c92df873b0a4de12eb1a21e
chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Nov 16, 2018
Recent CSS WG decision
w3c/csswg-drafts#3258

Bug: 568705
Change-Id: If24be4b2c0a49ba12c92df873b0a4de12eb1a21e
aarongable pushed a commit to chromium/chromium that referenced this issue Nov 16, 2018
Recent CSS WG decision
w3c/csswg-drafts#3258

Bug: 568705
Change-Id: If24be4b2c0a49ba12c92df873b0a4de12eb1a21e
Reviewed-on: https://chromium-review.googlesource.com/c/1337227
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Eric Willigers <ericwilligers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608722}
chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Nov 16, 2018
Recent CSS WG decision
w3c/csswg-drafts#3258

Bug: 568705
Change-Id: If24be4b2c0a49ba12c92df873b0a4de12eb1a21e
Reviewed-on: https://chromium-review.googlesource.com/c/1337227
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Eric Willigers <ericwilligers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608722}
chromium-wpt-export-bot added a commit to web-platform-tests/wpt that referenced this issue Nov 16, 2018
Recent CSS WG decision
w3c/csswg-drafts#3258

Bug: 568705
Change-Id: If24be4b2c0a49ba12c92df873b0a4de12eb1a21e
Reviewed-on: https://chromium-review.googlesource.com/c/1337227
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Eric Willigers <ericwilligers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608722}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Nov 20, 2018
Automatic update from web-platform-testsCSS: rename :matches to :is

Recent CSS WG decision
w3c/csswg-drafts#3258

Bug: 568705
Change-Id: If24be4b2c0a49ba12c92df873b0a4de12eb1a21e
Reviewed-on: https://chromium-review.googlesource.com/c/1337227
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Eric Willigers <ericwilligers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608722}

--

wpt-commits: 4decb8ae3b8890851073d36cba9bb9a76f29e8d3
wpt-pr: 14071
jankeromnes pushed a commit to jankeromnes/gecko that referenced this issue Nov 21, 2018
Automatic update from web-platform-testsCSS: rename :matches to :is

Recent CSS WG decision
w3c/csswg-drafts#3258

Bug: 568705
Change-Id: If24be4b2c0a49ba12c92df873b0a4de12eb1a21e
Reviewed-on: https://chromium-review.googlesource.com/c/1337227
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Eric Willigers <ericwilligers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608722}

--

wpt-commits: 4decb8ae3b8890851073d36cba9bb9a76f29e8d3
wpt-pr: 14071
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Nov 21, 2018
Automatic update from web-platform-testsCSS: rename :matches to :is

Recent CSS WG decision
w3c/csswg-drafts#3258

Bug: 568705
Change-Id: If24be4b2c0a49ba12c92df873b0a4de12eb1a21e
Reviewed-on: https://chromium-review.googlesource.com/c/1337227
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Eric Willigers <ericwilligers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608722}

--

wpt-commits: 4decb8ae3b8890851073d36cba9bb9a76f29e8d3
wpt-pr: 14071
jankeromnes pushed a commit to jankeromnes/gecko that referenced this issue Nov 22, 2018
Automatic update from web-platform-testsCSS: rename :matches to :is

Recent CSS WG decision
w3c/csswg-drafts#3258

Bug: 568705
Change-Id: If24be4b2c0a49ba12c92df873b0a4de12eb1a21e
Reviewed-on: https://chromium-review.googlesource.com/c/1337227
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Eric Willigers <ericwilligers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608722}

--

wpt-commits: 4decb8ae3b8890851073d36cba9bb9a76f29e8d3
wpt-pr: 14071
SergioOpenPeer pushed a commit to webrtc-uwp/chromium-tools that referenced this issue May 10, 2019
Recent CSS WG decision
w3c/csswg-drafts#3258

Bug: 568705
Change-Id: If24be4b2c0a49ba12c92df873b0a4de12eb1a21e
Reviewed-on: https://chromium-review.googlesource.com/c/1337227
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Commit-Queue: Eric Willigers <ericwilligers@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#608722}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 5343c104d0cfa80218a288caee0cb265d0d4691a
domenic pushed a commit to whatwg/html that referenced this issue Jul 7, 2020
* Change :matches() to :is() per
  w3c/csswg-drafts#3258.
* Fix missing quotes in iframe[frameborder='0'] since 0 is not an ident
  or string.

Closes #5703.
mfreed7 added a commit to mfreed7/html that referenced this issue Sep 11, 2020
* Change :matches() to :is() per
  w3c/csswg-drafts#3258.
* Fix missing quotes in iframe[frameborder='0'] since 0 is not an ident
  or string.

Closes whatwg#5703.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

You can’t perform that action at this time.