[selectors4] Name the “functional pseudo-class like :matches() with 0 specificity”

[fantasai]

In Issue #1170 we decided to add a functional pseudo-class that is exactly like :matches() but has zero specificity. However, we didn't decide on a name.

Suggestions in that thread included :is(), :when(), :filter(), and :nospecificity(). It was noted that having :filter() as a selector and filter s a property might be confusing, and that :nospecificity() is a pain to type. Additional suggestions, comments, and clarifications welcome.

[LeaVerou]

I would vote for :is(). It's short, and it explains what it does. IIRC most people were in favor of :is() both in the thread and at the F2F. If you want an explicit resolution, we could add it to the agenda.

This is the twitter thread where I asked authors for ideas: https://twitter.com/LeaVerou/status/928426600558862337 As you will see, the results are not very useful.

Regarding the other names:

• :when sounds time-related
• :nospecificity is ridiculously long and prevents any possibility of expansion in the future to allow setting specificity, as @tabatkins suggested.
• :filter is confusing because it sounds related to the filter property and the filter() function.

[SebastianZ]

:nospecificity is ridiculously long and prevents any possibility of expansion in the future to allow setting specificity, as @tabatkins suggested.

At least the latter point could be avoided, of course, by using :specificity() instead. Nonetheless it's still very long and hard to write.

So, I also vote for :is(), even when it rather indicates a check and not something to set the specificity.

Sebastian

[SelenIT]

I'm for :is(), as it :is() easy to memorize as kind of acronym for "Ignore Specificity" :)

[Loirooriol]

Since #1170 was already resolved it may be too late for this, but shouldn't #1027 be resolved before adding a new functional pseudo-class?

It seems probable to me that the specificity of :matches needs to be fixed to avoid performance problems in some cases, and then :is could become redundant.

[SelenIT]

I’m not sure that :matches() can, and needs to, be “fixed”. For me, the summary of #1027 is that :matches() doesn’t have any special performance problems per se (except it allows to write seemingly short selectors equivalent to terribly long selector lists, but this problem is not new, it often occurs with CSS preprocessors as well). Also, :matches() has been supported in Safari since 2015, and there is intent to implement it in Chrome, so changing it can break the interoperability. And, AFAIK, it wasn’t meant to affect specificity in any way, it’s sole purpose was to be syntactic sugar for shortening the lists of selectors with common parts for readability and reducing style bloating. The :is() selector, on the other hand, was introduced specifically to explicitly control the specificity, so I doubt that it could become redundant.

[Loirooriol]

Yes, just syntax sugar, but the problem is that if you just desugar it naively then you get an exponentially-long selector. Preprocessors don't matter, what matters is the CSS they produce, and it's acceptable for a CSS engine to take more time if the CSS is absurdly huge. But if the CSS is not huge, then it should be fast (e.g. that's why :has is not allowed in the dynamic profile).

If Safari implemented :matches, maybe there is some efficient algorithm. But I suspect they might not be calculating the specificity of :matches on the element that ensures a maximum specificity, which probably is what the spec should properly define. Sadly I have no Mac to test.

[fantasai]

My concern with :is() is that it will be logically seen as the inverse of :not(), even though the inverse of :not() is :matches(): the specificity behavior of :not() and :matches() are matched, and :not(:not(selector)) behaves as :matches(selector), not as :is(selector). But linguistically “is” and “not” seem to form a pair.

[Loirooriol]

What about swapping :is and :matches, then? So :is would be analogous to :not and :matches would have 0 specificity.

[SelenIT]

Well, maybe then we can avoid the confusion if we could use the pattern proposed in #1170 by @tabatkins and add an extra optional argument to the existing :matches() instead of duplicating its functionality in a new pseudo-class at all?

So while :matches(...) would behave as it currently does, for example, :matches(... as 0,0,0) would have the behavior of the proposed :is() (zero-specificity matching), and :matches(... as 0,1,0) would match any of its arguments with the specificity of the single class. It would be backwards compatible with the existing :matches() implementations and wouldn't introduce any ambiguity in what is the inverse of :not(). Moreover, the similar extra argument could be added to :not() as well, making the behavior of :not() and :matches() symmetric.

Or is it too late to make such changes in Level 4?

[LeaVerou]

Yup, we could rename :matches() to :is() and introduce an extra argument, which could only be 0 at first, and later expand to the full specificity triplet. I.e. div:is(#foo, as 0).

[SelenIT]

Wouldn’t renaming :matches() require making it an alias for :is()? Or will it make the existing WebKit’s shipped implementation (and probably the Blink’s implementation being currently developed) non-conforming?

[tabatkins]

We're not renaming :matches(); it's already shipped in Safari and I think Firefox and Chrome are soon to ship?

I'm still okay with just adding the functionality to :matches(), with the default being the current "specificity of the most specific branch that matched". If we do make a separate function, I'm still happy with :is(); the possibility for confusion is there, but oh well.

[inoas]

So since when has short-lived vendor implementation ruled what happens to a standard?

I don't get it what's wrong, this is not yet another piece of software that you (or someone else at big-vendor-x) can throw away in some years and replace it with something else entirely and somehow I got the feeling that that's the recent predominant mind set. /rant :-(

Without much details to rephrase what @fantasai says:

• If :not() and :matches() are the inverse of each other they should have inversed names for easy understanding and usage.
• If :is() and :not() have inversed semantic meaning, they should behave like that and not unexpectedly do something else.

Logical options that make sure developers in future are not the hell confused about it (and TWBS-div-soup-hell shows most, are):

• A) Rename matches() to is() - use matches() for the new 0-specificity feature discussed here.
• B) Alias is() and matches() and find a new name for the feature proposed here instead of matches().

So why don't we collect alternate names for the current matches()-proposal and if we can find something really reasonable we can alias is() and matches() and deprecate matches()? What's so wrong about that?

[inoas]

If my last comment is true, that would leave us with:

• :nospecificity() - Agreed that it is hard to type, long, wants me to write :no-specificity() instead, wants me to add typos to "specifity" by accident and leaves no option to add specificity features later on. Pretty much worse than :is(), IMHO.
• :filter() - I rather much would have the same word in different contexts doing different things (as expected), than logical pairs of words doing something else (:is() vs :not()).
• :when() - I don't think the interpretation as only "time" related is a problem @LeaVerou? LESS, Elixir and PostgreSQL use it for logical conditions just fine, so why is ":when sounds time-related" a problem?

So these are all sane options without creating unexpected developer pain:

1. Use matches() for the new implementation and rename current matches() implementation in the wild to is() - Issue: Vendor Safari has to adapt.
2. Use when() for the new implementation and alias current matches() to is() and deprecate matches() - Issue: None?
3. Use filter() for the new implementation and alias current matches() to is() and deprecate matches() - Small Issue: re-use of the same word in different context means it does different things.

Edit, here are some more from @LeaVerou's Twitter post.

• :extend()
• :decorate()
• :augment()
• :if()
• :catch(), and I'd like to add:
• :apply()
• :case()

[tabatkins]

Aliasing :matches() doesn't do much of value; the name as it stands is fine, so it's not worth adding yet another name for the same functionality. That just makes it harder to teach and understand.

Renaming :matches() is rude to the implementors at this point, and to the authors who've already learned it. We've had the function for a long time, implementors have begun implementing with it. If the name was truly bad or misleading we could probably rename it, but it's not - at worst, it's slightly annoying that :is() appears to be a slightly better antonym to :not() than :matches() is, so people new to the feature might get confused, but it's quick to learn which is which. At this point in the feature's maturity, I don't think this justifies making a name change.

[SelenIT]

@inoas, AFAIK, :matches() is not just "short-lived vendor implementation". It has been in the standard draft for years (although the definition has changed a little), and its shipped implementation, without any flag/prefix, has existsed since mid-2015 (deprecating the old vendor-specific :-webkit-any() implementation), and there is intent to implement it in Blink (1, 2). So there should be some really solid reasons to rename/alias it (IMO).

Hovewer, I agree with Tab that the potential confusion in meaning between :matches() and :is() is not a very important issue. So I'm also fine with the both options — either introducing :is() as a functional analog for :matches() that ignores specificity (as currently specified), or "overloading" :matches() with an optional extra argument, without adding new pseudo classes at all.

[LeaVerou]

In the past we would keep bad things only to avoid breaking web compat. Now we're keeping bad things to not be "rude" to implementors? What fresh hell is this?! 😛

:matches() has shipped in one browser and is not used by anyone. Renaming things is typically easy for implementors, and since nobody uses it (outside of postCSS) it doesn't break web compat.

What troubles me more is that I expect :is() to be used many more times in a selector and the lengthier :matches() would end up messing with readability. :matches() is only used for > 1 alternatives, whereas :is() is useful for singular things too. I think a name for :is() that's longer than 2-3 characters would be a pain.

[fantasai]

@leaverou I will note that most of your examples are chains of :not() which in Level 4 could be expressed within a single :not(), which won't explode the specificity in the same way. E.g. :not(.A):not(.B):not(.C) (specificity=0,3,0) can be written as :not(.A, .B, .C) (specificity=0,1,0).

[tabatkins]

In the past we would keep bad things only to avoid breaking web compat. Now we're keeping bad things to not be "rude" to implementors? What fresh hell is this?! 😛

It's not a "bad" thing. It's a perfectly serviceable and appropriate name that people were happy with for multiple years; two people in this thread suddenly expressing a preference for a slightly different name does not make the original name bad.

Changing things that have shipped, are about to be shipped, that have tutorials written about them, etc., is expensive. It's one more thing a browser implementor has to do (even if it's "trivial", it's still a chunk of time out of someone's day to update the parser, the tests, maybe the DevTools support, and that chunk could have been spent doing something more valuable), and it means a lot of tutorial content in the wild is invalid and needs to be updated, or is just confusing in the future. In other words, renaming is not free, and the longer the name lives out in the wild, the more expensive it becomes. This doesn't mean we can't do it, but it does mean we need a decent reason to do so, and "some people suddenly decided they like this alternate name slightly better" is not a very good reason, or at least not a good enough one to override the costs in this case, in my opinion.

[inoas]

Well @tabatkins it is not like the only option is renaming aliasing and adding is(), actually when using when() here for this proposal there is the option (not) to later on alias is() with matching() and/or make it a separate stand-alone issue as it is not strictly related then, anymore.

Using when() would also circumvent the issue of semantic (but proposed non-functional) pairing of is() vs not().

Would that be viable?

@LeaVerou maybe Brent Spiner knows.

[LeaVerou]

@LeaVerou I will note that most of your examples are chains of :not() which in Level 4 could be expressed within a single :not(), which won't explode the specificity in the same way. E.g. :not(.A):not(.B):not(.C) (specificity=0,3,0) can be written as :not(.A, .B, .C) (specificity=0,1,0).

Just because it's easier to demonstrate the problem with :not() because typically removing something very specific from a large set still leaves you with a large set, so its specificity is almost always not what an author wants. Note that div:not(#foo, #bar, #baz) has the same problem, just less specificity. It's still pretty hard to override even just one id selector.

However, the problem :is() is trying to solve extends way beyond :not(). I could go through my stylesheets and compile a list of use cases that have specificity problems and don't include :not(). Thankfully, we have a resolution on this, so my time can be spent more productively. Can we please focus on the name?

I think @SelenIT made an excellent point about :is() being an acronym for Ignore Specificity.

[fantasai]

Thankfully, we have a resolution on this, so my time can be spent more productively. Can we please focus on the name?

I'm not disputing that we should have this feature, just the frequency with which it would be needed that is driving you to require its name to be two characters.

I think @SelenIT made an excellent point about :is() being an acronym for Ignore Specificity.

And as you so often like to point out, nobody reads documentation, so my point about the misleading pairing stands, however clever the backronym might be.

[Nadya678]

Should the :is() have specificity like :not()? What specificity has :has()?

[ewilligers]

What specificity has :has()?

:has is only available in the snapshot profile, thus I suspect it doesn't need to have defined specificity. The query() method does not consider specificity.

[fantasai]

Should the :is() have specificity like :not()?

@Nadya678 :matches() behaves like :not(): it takes the specificity of its argument. The proposed :is(), which otherwise behaves exactly like :matches(), has a specificity of zero.

What specificity has :has()?

Good question. It looks like we forgot to define it when we switched from having a subject indicator to using :has() syntax. I've updated the Specificity section now--it has the specificity of its argument, just like :matches().

[fantasai]

Another option, fwiw, would be to use bare parens for eliminating specificity. There are two possible interpretations of this idea:

A. Treat it like a pseudo-class syntax, except without the preceding :foo. B. The selector is interpreted exactly as if the parentheses weren't there, except that any selectors inside the parentheses aren't counted for specificity.

Example: foo(.a > .b) .c -- A would match this as foo:matches(.a > .b) .c whereas B would match it as foo.a > .b .c

For case B, if it's considered weird, we could say that the parens can't cross hierachical boundaries, i.e. that example above would be invalid, but you could write foo(.a) > (.b .c) to mean the same thing.

[tabatkins]

That syntax doesn't work; it confuses the parser and produces paren-blocks in some cases, but function-blocks in others, and when it looks like a function, it isn't one. foo(.a > .b) appears to be a function named foo() to the parser.

[LeaVerou]

Another option, fwiw, would be to use bare parens for eliminating specificity. There are two possible interpretations of this idea:

I was wondering about something like this, perhaps an empty pseudo-class (foo:(.bar)). But is this important enough to be privileged like this? It might be, but since we can only allocate the empty pseudo-class once we need to think about this.

[tabatkins]

My opinion is: strongly no. We shouldn't allocate the "empty pseudo-class" for anything at all, imo - it's an impossible syntax to google for or even to talk about casually.

[inoas]

Is this not a concern to anyone but @fantasai and me?

My concern with :is() is that it will be logically seen as the inverse of :not(), even though the inverse of :not() is :matches(): the specificity behavior of :not() and :matches() are matched, and :not(:not(selector)) behaves as :matches(selector), not as :is(selector). But linguistically “is” and “not” seem to form a pair.

So @LeaVerou what about :when() then or :case()?

[SelenIT]

Maybe it's worth considering :as() instead of :is()? Still only 2 letters, but it clearly doesn't pair with :not(). It implies that the selector is basically still the main selector (part before :), but in a special state or situation where it acts (also) as another selector, where it "mimics" that other selector, where it only plays its role — which quite intuitively describes what this selector does (at least, for me).

[LeaVerou]

I like :as()! :case() is unclear and :when() sounds time-related (as I said in the second comment).

At this point, we have been bikeshedding names for a month (9 months if you start counting when the initial proposal was posted). We have seen many proposals, and I don't think a clearly better one will magically emerge if we discuss this for another month. The feature has already started being shared amongst authors, presented in a Google podcast, and people are generally excited, so as important as naming is, it would be good not to hold it up further with even more bikeshedding.

I will go ahead and add this to the agenda for next week, so we can do a straw poll and finally decide. Hope that’s ok with you @fantasai!

Here is a summary of all proposals (feel free to edit my comment to add pros & cons, or any proposals I missed):

Name	Pros	Cons
:is()	short, meaningful, backronym for "Ignore Specificity".	logical opposite of :not()
Rename :matches() to :is(), use argument for specificity	Avoids 2 pseudos for same functionality, logical opposite of :not(), short	:matches() shipped in Safari and in draft for years
:matches() (and rename :matches() to :is())	:is() is the logical opposite of :not()	Long, :matches() shipped in Safari
:matches(...,... as 0,0,0)	Avoids 2 pseudos for same functionality	Looks like a single list with entries ..., ... as 0, 0, 0
:when()	meaningful	looks time-based
:if()	Short	People might also expect :else
:also()	implies argument has subsidiary role	?
:as()	short, not opposite of :not()	Sounds similar to :has()
:filter()	?	Confusing, looks related to the CSS filters
:nospecificity()	Explains exactly what it does	Way too long, can't be extended to specify specificity
:extend()	?	Sounds related to @extend
:decorate()	?	Too long, convoluted
:augment()	?	Too long, convoluted, especially for non-native speakers
:catch()	?	Confusing, Sounds error-related
:apply()	?	?
:case()	?	unclear
:switch()	?	?
:cond()	?	?
:isset()	?	?
:defaults()	?	may be confused with :default
:something()	?	?
:selects()	?	?
:where()	used to winnow sets in SQL	?
:fallback()	means an alternative when nothing more specific is available	?
:general()	antonym of specific	?
:sub()	lower level or position, abbreviation of substitute	?
:weak()	means being susceptible to substitute	?

[fantasai]

I'm not sure I follow the logic for :as(); to me it implies we're translating the selector to its argument.

But maybe add :also() to the list? (It's almost as short, indicates conjoining the restrictions in its argument to what's it's attached to; but also implies a structurally-branching or subsidiary role for its argument, so making it “less important” by dropping its specificity fits into that connotation.)

[ewilligers]

:has and :as sound very similar.

[therealglazou]

We're not renaming :matches(); it's already shipped in Safari and I think Firefox and Chrome are soon to ship?

Could we have metrics about current :matches() usage in the wild? @inoas 's argument « So since when has short-lived vendor implementation ruled what happens to a standard? » does ring a bell here. If, as @LeaVerou says, :matches() is unused or almost unused (plausible since 95% of the market does not have it yet), we have NOW a window of opportunity to change it if we want.

That said, I am not sure I like the "as" extra argument proposal. In terms of parsing, we would need a separator between the end of the last compound selector and the specificity marker to avoid confusion with a "as" type element selector... The easiest to use is the comma but then we have the same problem again, the selector list parser will resume with "as" and only a look-ahead will help; but still, what if I'm applying "as f0" selector to my own XML dialect where "as" and "f0" are real elements but I make a typo and drop the leading "f"? Is that a buggy selector list or a buggy specificity marker? All in all, the ", as ..." solution seems to me too hacky. I have then a preference for two pseudos, one with a specificity and a second one without.

Extra note, I don't like the fact that two features having same exact definition if you except the specificity have too different names. That's why I don't really like :is(). I would prefer :matches() and :matches-blah() with a good choice for blah...

AFAIK, :matches() is not just "short-lived vendor implementation". It has been in the standard draft for years (although the definition has changed a little), and its shipped implementation, without any flag/prefix, has existsed since mid-2015 (deprecating the old vendor-specific :-webkit-any() implementation), and there is intent to implement it in Blink (1, 2). So there should be some really solid reasons to rename/alias it (IMO).

A "draft" is NOT a standard. Second, Selectors 4 have never been in CR, and :matches() has never been in a REC-track version of Selectors 3. So this is yet another occurrence of vendors potentially disturbing standardization with a "shipped, can't change" argument and, holy cow it's 2018, could vendors please stop doing that? Oh but wait, it's not even shipped yet, an "intent to ship" is not "shipped". It smells far too much like 1997 Microsoft and, fortunately, Microsoft stopped doing that two decades ago.

[SelenIT]

@therealglazou thanks for your very well reasoned answer! You make some excellent points.

I agree that "as" syntax for extra argument wasn't a good idea. But maybe with better way to do it (e.g. with a simple comma separator, as in @tabatkins's initial proposal) the idea to reuse the same pseudo-class for both default-specificity and zero-specificity/custom-specificity matching would be not so bad? At least, it completely solves the "different names for the exactly the same thing except..." problem.

Unfortunatly, Apple has shipped the :matches() (and several other selectors from Level 4) implementation with no prefixes or flags back in 2015, in Safari 9.0. I agree that doing it while the spec was far from CR was not the right move from Apple. However, as @tabatkins mentioned, :matches() is now not only in the spec draft and Apple's implementation, but also in many docs and guides for web devs, in the compatibility tables like caniuse.com, in the lists of modern CSS features like cssdb (where it is marked as "Allowable"), and there are polyfills and PostCSS plugins for it. Changing it without really good reasoning would punish not only Apple, but also authors and users of all these resources. There are also many CSS features (e.g. transforms, transitions and animations) that are implemented with "rough interoperability" and are widely used despite having never been in CR. I'm afraid that making CR status too important could possibly lead to "no implementation before CR/no CR before two implementations" deadlocks.

[LeaVerou]

A "draft" is NOT a standard. Second, Selectors 4 have never been in CR, and :matches() has never been in a REC-track version of Selectors 3. So this is yet another occurrence of vendors potentially disturbing standardization with a "shipped, can't change" argument and, holy cow it's 2018, could vendors please stop doing that? Oh but wait, it's not even shipped yet, an "intent to ship" is not "shipped". It smells far too much like 1997 Microsoft and, fortunately, Microsoft stopped doing that two decades ago.

Very well said!

Btw, may I remind you all that gradients were shipped everywhere and we changed their syntax for much less serious reasons than those described here.

[fantasai]

@therealglazou While I don't disagree with your argument in general, I do want to point out that Selectors 4 is dramatically behind process-wise, largely my fault since I have neglected it the last few years, and the features that Apple shipped were largely considered to be stable, so I don't fault them for shipping under the circumstances. I think @SelenIT's arguments are also important to consider. Nonetheless it would be good to collect some data. :is() as the opposite of :not() would be pretty nice to have, if it's possible to pull off--and it might be if the specificity of existing stylesheets’ :matches() arguments are shown to not matter in practice.

@LeaVerou Thanks for maintaining the table. :)

[tabatkins]

In addition to what @fantasai said...

Btw, may I remind you all that gradients were shipped everywhere and we changed their syntax for much less serious reasons than those described here.

The major churn we introduced with gradients was a terrible mistake and I wouldn't repeat it if I could go back in time. It's absolutely not appropriate to point to as a precedent.

[FremyCompany]

I spent some time reading through the comments and still like input:when([type=number]) better than any of the alternatives.

Also, even though Edge does not support the :matches pseudo nor plans to support it at the moment, I would like to agree that :matches is a reasonable name, and does not need to be changed. I'm highly sympathetic with implementors having a feature shipped for years then ultimately having no advantage of it whatsoever because everything gets renamed in the end. The work required to rename a feature is much more important than it seems. You have to update the tests, the comments, the function named after it; seriously I wouldn't want to impose this on Safari if there isn't a clear and obvious reason.

[SelenIT]

@FremyCompany, how significant is the difference between input:if([type=number]) and the :when() version? For me, they seem nearly synonymous in this context, but :if() is shorter and doesn't look time-related...

[ionas]

Could add :cond() to the table?

For :apply() negative would be that it is hard to imagine to "apply a selector" and apply leads to thinking of applying css property lists instead... that can be confusing for new users.

@LeaVerou what's the fuss with when and being time-related. Is that so bad?

Again I will cite how guards work in some languages, and IMHO the thing this new selector should do is pretty much close go guards: The function signature (the selector + specificity) does not change, but we add some additional conditions under which it varies/should be executed:

• when as a guard in LESS http://lesscss.org/features/#mixin-guards-feature
• when as a guard in Elixir https://hexdocs.pm/elixir/master/guards.html#why-guards

There is also when as a conditional clause in SQL (which also leads to case): https://www.postgresql.org/docs/9.4/static/functions-conditional.html https://docs.microsoft.com/en-us/sql/t-sql/language-elements/case-transact-sql

There is also :case() and maybe :switch() could even be used as you could use the same selectors with different switches (or cases, or conds https://elixir-lang.org/getting-started/case-cond-and-if.html#cond - without adding specificity when doing so to apply some basic styles).

Then CSS is - aside transitions - not about time/timing, but declarative like say SQL. So where is the problem with when exactly sounding "time-based"? I can't follow. when is even part of of LESS so people familiar with LESS (or guards in general) will quickly understand :when().

Out of the current table I like :when() the most as the concept of guards is very close to what this new selector here should do, imho. After that I do like :also() which could be a great name for a guarding statement in other languages as well IMHO: Match me by this function name and signature and also make sure these constraints are met.

@FremyCompany :if() has a very procedural feel to me, next time around people try :else(). Other than that I am with you on being close to when() latter to me feels more like a short whenever() in declarative languages.

[SelenIT]

CSS is - aside transitions - not about time/timing

@ionas, it wasn't, but since the same CSS Selectors Level 4 spec that we discuss here introduced Time-dimensional pseudo-classes, things became a bit more complicated. However, your other arguments for when sound quite reasonable.

[FremyCompany]

@SelenIT :if sounds fine by me, I hadn't seen that proposal

[css-meeting-bot]

The Working Group just discussed [selectors4] Name the "functional pseudo-class like :matches() with 0 specificity", and agreed to the following resolutions:

• RESOLVED: Publish a new WD for Selectors adding the open items as issues.

The full IRC log of that discussion

<dael> Topic: [selectors4] Name the "functional pseudo-class like :matches() with 0 specificity"
<dael> github: https://github.com/w3c/csswg-drafts/issues/2143
<leaverou> https://github.com/w3c/csswg-drafts/issues/2143#issuecomment-360586470
<dael> leaverou: We resolved a month ago to add a pseudoclass :is . There was consern that that's logical opposite of not. Proposal is we could rename matches to is, we could rename matches, we could combine both properties. There were a bunch of proposals for different names. I made a table with proposals ^
<dael> leaverou: Hoping we could do a straw poll and decide on name.
<dael> leaverou: I think best is to mix them into one pseucoclass of :is. Matchs was impl but it's not used and is only in Safari. It is considered rude to rename.
<fantasai> I don't think we can close on this fairly in the next 4 minutes...
<fantasai> 3 minutes
<dael> florian: rude isn't the best word, but there is inertia there and it's a lot to change.
<dael> smfr: I don't have a feel for how much matches is used.
<bradk> This could be a 30 minute discussion
<dael> fantasai: We have 2 minutes. I'd like us to defer this since there has been a lot of interesting discussion. And we should have info on existance of matches.
<dael> leaverou: I won't be able to be in next week, so defer 2 weeks.
<dael> fantasai: Sure.
<dael> Rossen_: This topic will take time. Let's point everyone to the issue so it's discussed.
<dael> Rossen_: fantasai you wanted an updated WD?
<dael> fantasai: Yeah, to selectors. There's a handful of open issues that are significant and they're marked in the draft. I'd like to update the W3.org.
<dael> RESOLVED: Publish a new WD for Selectors adding the open items as issues.
<dael> Rossen_: This topic should continue being discussed in the issue and once we're ready to resolve we'll bring it back. A couple of weeks from now sounds reasonable on timeframe.
<fantasai> Issues marked in the draft: https://drafts.csswg.org/selectors-4/#issues-index
<dael> Rossen_: That's the top of the hour. Any other publication resolutions? I don't see any.
<dael> Rossen_: Let's end here.

[CyberAP]

As we're testing what's actually set or not within the pseduo-class selector I liked the idea of calling it isset:

:isset(.foo, .bar) .baz

In terms of googling that would be easier to find than a simple :is or :as.

That, however, doesn't tell us that this selector is not specific, but that's a general problem of using a pseudo-class for this task I think. If more of these selectors are coming I'd prefer to see them separated into a new selector type rather than trying to fit into an existing pseudo-class system.

If we're to stick with the pseudo-class, then we could be looking at this from a functional side of things. What this selector is actually tries to do is to set a default value that can be easily overridden, so :defaults() comes to mind.

However, there is a :default pseudo-class and that may of course confuse people.

[js-choi]

Left comments notifying of this issue on existing bugs for Chromium bug 568705, Firefox bug 906353, and WebKit bug 56990.

[Tyler-H]

It sounds like a joke, but frankly :something() as named by fantasai has an unexpected elegance to it; "something" is about as broad/vague as you can be... considering this is something that sets specificity to 0 (essentially canceling all specificity), I would say a broad term personifies what you're trying to do here considering the name of the subject matter at hand (specificity).

Understandably this isn't intuitive, so it most likely won't be kept, but I felt obligated to remark on the simple elegance of the temporary name.

[phistuck]

What about the naturally related (selector selects...) :selects?

[evanminto]

Just a member of the community chiming in here. I think a big reason not to move off of :matches() that hasn't been mentioned in this issue is the DOM method Element.matches(). Developers may be familiar with both the JS and CSS features, and renaming just one of them even though they serve similar purposes (with identical selector syntax) is likely to be pretty confusing.

Though I agree the :not() vs. :is() thing is a bit confusing, I also think there's something kind of logical about :is() vs. :matches(). "Is" feels like it's just the way the thing is, independent of selector logic, but "matches" feels like it kicks off a process to compute something, so the specificity rules are going to matter.

...at least that's the mnemonic I'd use to teach this to new devs!