Shouldn't this belong to @supports rule?
Just to imagine how bloated stylesheet would get if you have to use new selectors extensively. While with @supports you can only test it once and that's it.
Yes it doesn't cover selector check right now, but with Custom Selectors from CSS Extensions this should be possible.

@CyberAP, the point is to avoid having to write the same rules twice (for new and all browsers).

For example, consider a menu that is by default transformed into a hamburger icon (or something), but should "uncollapse" if either hovered or has a link inside it focused via keyboard. For modern browsers, I can write

.menu:hover, .menu:focus-within { transform: none; }

...but in browsers that don't support :focus-within this would not apply at all, and I would have to write this rule twice, for each selector separately, in order to make at least the :hover part work there.

However, with the new proposal, the following hypothetical example

:is(.menu:hover, .menu:focus-within, :current(.menu)) { transform: none; }

would be able to work in browsers that already support :is() and these two pseudo-classes, but don't support :current() yet.

How can this be solved with @supports (even if extended to test for selectors)? For me, this looks like the opposite of what @supports does (combining the code for old and new browsers into one rule, rather than separating it into different rules). Would be happy to be proven wrong!

@SelenIT, thanks for a great explanation! That does make sense and actually is a really great feature I would like to have.

You mean like #3082, except without the vendor prefix exemption?

Yes, and safely; I'm pretty sure we can't do #3082.

The CSS Working Group just discussed Let :matches() have better error-recovery behavior than normal Selectors, and agreed to the following:

• RESOLVED: Use media query style invalidation inside pseudo classes that accept selector lists

emilio pointed out that we need to be careful about how we handle :not() here. It's not obvious it would work as intended if we just ignore unknown arguments, and also a single argument to :not() likely has Web-compat implications since it's already implemented.

A related question is :nth-child(); simply ignoring one of its arguments could throw off the count. There likely wouldn't be a Web-compat problem with it, though.

The thing about :not() is that only the single‑argument form is supported in major browsers, so we could probably apply it to the multi‑argument form and be fine.

Also, at least for unknown pseudo‑classes, we could have those match nothing, so :not(:unsupported, :unsupported-2) would match everything because :not(:is(:unsupported, :unsupported-2)) would match everything, as :is(:unsupported, :unsupported-2) would match nothing.

I agree that we could minimize the Web-compat risk by saying that error recovery only applies if two or more selectors are supplied.

:nth-last-child(:nonsense) is invalid
:nth-child(:nonsense, :enabled) is :nth-child(:enabled)
:not(:nonsense, :gibberish) is *
:is(:nonsense, :gibberish) is :not(*).

This would have the following benefits:

• :not(.) and :nth-child(.) and :nth-last-child(.) with a single selector have the same semantics as in Selectors 3.
• We have error recovery for :is(...) and :where(...) and :has(...)
• :not(...) and :is(:not(...)) and :not(:is(...)) are always equivalent, same for :nth-child and :nth-last-child

As a minor variation, preserving the same benefits, we could say that error recovery only applies if at least one of the selectors is valid. Then

:not(:nonsense, :gibberish) is invalid.

This might be easier to teach, and avoid developers' confusion when they see an introduced :not(*) in a Developer Tool that hasn't preserved raw text.

As a minor variation, preserving the same benefits, we could say that error recovery only applies if at least one of the selectors is valid.

Then :not(:nonsense, :gibberish) is invalid.

That should probably only apply to :not(…), as :commonly-supported, :is(:rarely-supported) can be used to avoid invalidating the entire selector list if the :rarely-supported pseudo‑class isn’t supported by the current browser but :is(…) and :commonly-supported are supported by the current browser.

Also, it might be a good idea to still parse :not(:nonsense, :gibberish) as valid, but matching nothing.

For :not(), I added Blink use counters.

kCSSSelectorNotWithValidList
6% of pages have :not() with 2+ selectors, all valid, or a valid non-simple selector, e.g. :not(*, *) or :not(* + *)

kCSSSelectorNotWithInvalidList
4.5% of pages have :not() with no valid selectors, e.g. :not(:nonsense)

kCSSSelectorNotWithPartiallyValidList
0.09% of pages have :not() containing both valid and invalid selectors, e.g. :not(*, :nonsense)

We haven't discussed what dev tools, etc., should show when the author provided :is(:nonsense). Do people prefer :is() or :is(:not(*))? This might not be a spec issue.

I think displaying it as :is(:nonsense ⚠️) might be the best option.

The CSS Working Group just discussed Error recovery for :is() and :not(), and agreed to the following:

• RESOLVED: Drop individual invalid selectors from selector lists in *all* selector functions that take such lists, *except* for :not().

What should happen if someone were to write:

:is(h1, h3), :is(h2:maybe-unsupported) { font-family: sans-serif }

I believe that it should be treated as if the following was written in browsers that don't support :maybe‑unsupported, but support :is(…):

:is(h1, h3) { font-family: sans-serif }

I'm all for this, but it will interact surprisingly with selector nesting, since a, b { & c, &d {}} becomes :is(a, b) c, :is(a, b) d{}.

It makes nesting forgetgiveful except at the last level... So c or d resulting in a parsing error will cause the rejection of the last nesting level.

Drive-by comment: seems that in Firefox 78+, and the upcoming Safari 14 (currently in the Technology Preview stage), the :is() and :where() pseudo-classes become invalid when an invalid selector is included in the list. For example, document.querySelectorAll('div:is(div, :bogus)') throws in both.

Agenda+ to look into the problem raised by #3264 (comment), and to consider whether compat is starting to paint us into a corner here.

I'm happy to implement this in Gecko if people define in the spec how to deal with the empty-selector behavior. Like, should :is(:nonsense) serialize just as :is()? Should that be special-cased to never match?

Also, it may be a bit confusing if people write stuff like :is(::before, ::after), and it gets turned to :is() instead of being rejected as invalid...

Then, of course :is() should be parseable too...

should :is(:nonsense) serialize just as :is()? Should that be special-cased to never match?

Then, of course :is() should be parseable too...

Yes, I was going to serialize :is(:nonsense) as :is() in dev tools, and treat :is() as a valid selector that never matches.

Is serialization of selectors web exposed, i.e. testable in WPTs?

@ewilligers Sure, include /css/support/parsing-testcommon.js and then

test_valid_selector(":is(:nonsense)", ":is()");

The CSS Working Group just discussed [selectors] Let :is() have better error-recovery behavior than normal Selectors.

https://bugzilla.mozilla.org/show_bug.cgi?id=1664718 is the Gecko bug for this (sorry for the lag, busy month!). I plan to enable it on Nightly and beta for now to collect potential breakage, but will enable after a couple releases everywhere if there's no issue.

Just verifying as I write the spec - in #3264 (comment) @ewilligers suggested that we handle "single selector, which is invalid" differently from the rest of the cases, since that has legacy implications, but it looks like we're no longer doing that?

That is, :is(:unknown) is valid but matches nothing, just like :is() and :is(:unknown1, :unknown2)?

Yes, that's what I implemented, fwiw. I don't see why "single invalid selector" should be different.

Cool, then please make sure the spec edits linked above are satisfactory; they apply to :is(), :where(), and :has(), but not :not(), per resolutions earlier in the thread.

They look good. I'd probably note that there's an interesting side-effect of this behavior which I'm not sure it's great, which is that the specificity of :is(:unknown, div), will change when a browser starts supporting :unknown. I don't see a great way to avoid that though.

Yeah, unless I distinguish between "parsable, just using unknown selectors" and "lol wtf is this", I can't handle that.

And even then, a "parsable but unknown" selector might have complex specificity behavior, so we actually can't even predict that. So it's just something we'll have to accept.