906353 - Add support for css4 selector :is() (formerly :matches()), the standard of :-moz-any().

Status: RESOLVED DUPLICATE of bug 1509418

(Core :: CSS Parsing and Computation, enhancement, P3)

Description

[rexyrexy2]

:matches() is the standardized version of :-moz-any(). We already have :-moz-any(), which essentially has the exact same functionality as :matches(). all you need to do is add the functions of :-moz-any() to work with :matches() as well. This should be a walk in a park to implement, so you may as well implement it, as it is very unlikely to change, it would make firefox have a better score at the css4 selector test, and it would add yet another selector to the list of standard selectors on Firefox.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to rexyrexy2 from comment #0)
> :matches() is the standardized version of :-moz-any(). We already have
> :-moz-any(), which essentially has the exact same functionality as
> :matches(). all you need to do is add the functions of :-moz-any() to work
> with :matches() as well.

I'm not sure they're exactly the same.  Do all the statements in http://dev.w3.org/csswg/selectors4/#matches about interaction with :not() match the behavior of :-moz-any(), for example?

> This should be a walk in a park to implement, so
> you may as well implement it, as it is very unlikely to change, it would
> make firefox have a better score at the css4 selector test, and it would add
> yet another selector to the list of standard selectors on Firefox.

I'm not convinced that it's "very unlikely to change".  I'm a member of the CSS working group, and I don't think selectors4 has gotten all that much review yet, although it has had a bit.


It's also not yet in CR and the working group hasn't agreed that it's stable, which means we shouldn't implement it without a prefix yet.

Comment 2

[Mardeg]

(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #1)
> It's also not yet in CR and the working group hasn't agreed that it's
> stable, which means we shouldn't implement it without a prefix yet.
Is it current practice to implement experimental CSS features with a prefix or hidden behind a pref?

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

In general, behind a pref.  Though in the case of :-moz-any(), the original motivation was that we needed it internally, so if we were doing that today it probably would have been exposed to UA sheets even without the pref.

Comment 4

[rexyrexy2]

Yeah, but, if you have the functionality (or part of it) to begin with, why re-write it from scratch, when you can use the code you already have as a base to save time? Seems like a waste of time to write it from scratch if you already have the base functionality.

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I never proposed rewriting it from scratch, and a patch that did so would be rejected.  I was just saying that your claims about how trivial it is were exaggerated.

Comment 6

[Sebastian Zartner [:sebo]]

(In reply to David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) (vacation June 4-12) from comment #1)
> (In reply to rexyrexy2 from comment #0)
> > :matches() is the standardized version of :-moz-any(). We already have
> > :-moz-any(), which essentially has the exact same functionality as
> > :matches(). all you need to do is add the functions of :-moz-any() to work
> > with :matches() as well.

As far as I can see the specification allows complex selectors for :matches(), while :-moz-any() is restricted to compount selectors. So, there is already a difference between both.

Sebastian

Comment 7

[J. S. Choi]

There has been recent activity in the CSSWG around :matches() and whether to rename it to better reflect its relationship with :not(). However, Safari has publicly shipped :matches() for the past several months. See these GitHub issue threads:
https://github.com/w3c/csswg-drafts/issues/2143
https://github.com/w3c/csswg-drafts/issues/1027

Comment 8

[Emilio Cobos Álvarez (:emilio)]

This is not just unprefixing stuff. It actually requires compound selector support inside matches, for which invalidation is quite hard.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Err, wrong change

Comment 10

[ExE Boss]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #8)
> This is not just unprefixing stuff. It actually requires compound selector
> support inside matches, for which invalidation is quite hard.

Reading the specification, it says that `:matches()` takes a selector list as its argument without specifying the type of the selector list¹, which means that it actually requires complex selector support inside matches², which is even harder than compound selector support (a complex selector consists of compound selectors separated with combinators).

(a very lazy way of implementing this might be to just expand the :matches(…) selector into all possible combinations like what postcss-selector-matches does³)

¹ https://drafts.csswg.org/selectors-4/#matches
² https://drafts.csswg.org/selectors-4/#selector-list
³ https://www.npmjs.com/package/postcss-selector-matches

Comment 11

[Emilio Cobos Álvarez (:emilio)]

(In reply to ExE Boss from comment #10)
> (a very lazy way of implementing this might be to just expand the
> :matches(…) selector into all possible combinations like what
> postcss-selector-matches does³)

That will not work, it's what Blink tried and it's broken. See https://bugs.chromium.org/p/chromium/issues/detail?id=842157.

Comment 12

[Mats Palmgren (inactive)]

FYI, the CSSWG has renamed it:
> RESOLVED: Rename :matches() to :is() and deprecate :matches() in Safari and anywhere else using it
https://github.com/w3c/csswg-drafts/issues/3258#issuecomment-438742190

Comment 13

[709922234]

Safari supported

https://bugs.webkit.org/show_bug.cgi?id=209707

Comment 14

[Emilio Cobos Álvarez (:emilio)]

Patches up for this too in bug 1509418.