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

NEW
Unassigned

Status

()

Core
CSS Parsing and Computation
4 years ago
11 months ago

People

(Reporter: rexyrexy2, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {dev-doc-needed})

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

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

Updated

4 years ago
Blocks: 906354

Updated

4 years ago
Component: General → CSS Parsing and Computation
Product: Firefox → Core
(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.
Blocks: 693083
No longer blocks: 906354

Comment 2

4 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?
Flags: needinfo?(dbaron)
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.
Flags: needinfo?(dbaron)
(Reporter)

Comment 4

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

Updated

3 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

3 years ago
Keywords: dev-doc-needed

Updated

2 years ago
Depends on: 561154
(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
You need to log in before you can comment on or make changes to this bug.