Closed fantasai closed 5 years ago
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).
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()
.
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()
?
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.
Also, before I forget, how about considering :or()
instead? (to better match the or
operator in programming languages).
@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
.
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
.
The CSS Working Group just discussed Rename :matches() to :is()
.
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?
@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? :)
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
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.
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>
?)
@ewilligers When is Chrome planning to fully implement Selector Level 4?
@ewilligers When is Chrome planning to fully implement Selector Level 4?
The semantics for :is()
and :where()
may stabilize this month, when https://github.com/w3c/csswg-drafts/issues/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.
Breaking this one out from https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-433627117 ; @gibson042 wrote:
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()
:I believe other implementations besides WebKit are getting close to shipping
:matches()
so if we're renaming this, we need to do it asap.