rexyrexy2 Reporter
	Description • 11 years ago

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

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 1 • 11 years ago

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

	Mardeg
	Comment 2 • 11 years ago

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

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 3 • 11 years ago

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.

	rexyrexy2 Reporter
	Comment 4 • 11 years ago

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.

	David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)
	Comment 5 • 11 years ago

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.

	Sebastian Zartner [:sebo]
	Comment 6 • 8 years ago

(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

	J. S. Choi
	Comment 7 • 6 years ago

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

	Emilio Cobos Álvarez (:emilio) Assignee
	Comment 8 • 6 years ago

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

	Emilio Cobos Álvarez (:emilio) Assignee
	Comment 9 • 6 years ago

Err, wrong change

	ExE Boss
	Comment 10 • 6 years ago

(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

	Emilio Cobos Álvarez (:emilio) Assignee
	Comment 11 • 6 years ago

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

	Mats Palmgren (inactive)
	Comment 12 • 6 years ago

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