[selectors] consider preserving invalid selectors in :is() and :where()

[emilio]

In #7972 we resolved to preserve invalid selectors that contain an & as-is. It seems it'd be more consistent to do that for all invalid :is() / :where() branches like :is(:unknown). That's how @media and @supports behave.

[Loirooriol]

If invalid selectors are no longer dropped, :is() without arguments does no longer seem needed.

[tabatkins]

Yeah I think I'm fine with this. It certainly makes things more consistent, which is nice.

[cdoublev]

Preserving invalid/unknown <media-query> instead of replacing them with not all would also makes things more consistent.

edit: nevermind, this has already been resolved.

[css-meeting-bot]

The CSS Working Group just discussed [selectors] consider preserving invalid selectors in :is() and :where(), and agreed to the following:

• RESOLVED: preserve invalid selectors inside forgiving selector lists (such as :is() and :where()) regardless of whether there's an & in them

The full IRC log of that discussion

<dbaron> emilio: For nesting, when you have an & in a nested selector, we resolved to preserve the invalid selector inside so that you could properly track whether there was an &. Makes sense. But inconsistent, in the sense that it's a weird special case. Would be more consistent IMO to preserve all invalid selectors. That way you don't special case nesting. It's also more consistent with @supports and @media, with <general-enclosed>.
<dbaron> emilio: ... It feels more generally consistent. I don't think it matters particularly... I don't expect compat issues. The question is... as Oriol mentioned, this also makes the empty selector kind of silly.
<dbaron> TabAtkins: As a selectors editor, I agree, would be good to keep it ??? defined.
<dbaron> TabAtkins: not sure why we decided to drop the invalid selector arguments in :is()
<dbaron> emilio: implementation-wise, it's easier to just drop it, but if we need to preserve it, easier to preserve always rather than sometimes.
<ntim_> q+
<dbaron> emilio: So if nobody objects I think this would be better than the current specified behavior.
<bramus> +1
<Rossen_> ack ntim_
<dbaron> ntim_: Isn't there something about forgiving parsing?
<dbaron> emilio: That's the behavior of dropping invalid selector.
<dbaron> TabAtkins: nesting cares about whether there's an & at all, so you don't have a newer/older browser behavior switch.
<bramus> dbaron: so you would still be treating invalid selectors the same
<dbaron> dbaron: ... just preserving them in the OM.
<bramus> … but just not drop m
<dbaron> TabAtkins: yes
<dbaron> emilio: Proposed resolution: preserve invalid selectors inside :is() and :where() regardless of whether there's an & token.
<dbaron> ?: do for all forgiving selector lists?
<astearns> s/?/matthieudubet
<dbaron> TabAtkins: I think that's all of them for now, but we should say for all forgiving selector lists.
<dbaron> RESOLVED: preserve invalid selectors inside forgiving selector lists (such as :is() and :where()) regardless of whether there's an & in them

[cdoublev]

If invalid selectors are no longer dropped, :is() without arguments does no longer seem needed.

:is(), valid {} would become invalid, isn't it? Is it ok regarding back-compatibility?

---

TabAtkins: not sure why we decided to drop the invalid selector arguments in :is()

I think a good reason is that the author can see which selectors are invalid.

---

emilio: implementation-wise, it's easier to just drop it, but if we need to preserve it, easier to preserve always rather than sometimes

Isn't it also easier to serialize all selectors as is?

You parse :is(<declaration-value>#) and then you evaluate each <declaration-value> with parse a comma-separated list according to a CSS grammar (<complex-selector>). This could be applied to <media-query-list>.

edit: nope, sorry, <declaration-value> matches ,.

[emilio]

If invalid selectors are no longer dropped, :is() without arguments does no longer seem needed.

:is(), valid {} would become invalid, isn't it? Is it ok regarding back-compatibility?

Probably, since the only reasonable use-case for :is() is "all the other selectors were dropped". But we could keep :is() working, if needed for compat.

Isn't it also easier to serialize all selectors as is?

Not really, because then you need to preserve the specified string. Also it would be a pretty big behavior change (e.g. .foo /* whatever */ .bar would serialize as-is rather than with whitespace normalized and comments removed.

[cdoublev]

To be clear, I was suggesting to serialize the specified string of all selectors only in :is()/:where().

On second thought, I also think it is easier to only serialize invalid selectors as-is, which I interpret as with the specified string, rather than the component values.

Is it possible to serialize :is(##invalid, valid) without a whitespace between # and #invalid, without the specified string?

[tabatkins]

Is it possible to serialize :is(##invalid, valid) without a whitespace between # and #invalid, without the specified string?

Yeah, assuming you're reserializing from the token stream, that's the behavior you'd get by default. There's no whitespace token there, and the two tokens don't need a separator to re-parse successfully.

[cdoublev]

To parse as a forgiving selector list given an input input:

1. Parse a list of <complex-real-selector>s from input, and let selector list be the result.
2. Remove all failure items from selector list, and all items that are invalid selectors, then return a <selector-list> representing the remaining items in selector list. (This might be empty.)

Does preserving invalid selectors mean that step 2 will be removed and that items in selector list represent both the input and the result from its parsing, or that <forgiving-selector-list> will no longer be parsed with parse a comma-separated list according to a CSS grammar?

[tabatkins]

Neither actually - we need to preserve even things that fail to be a complex-real-selector at all (currently those will return failure). So I'll have to write something a little differently.

[sesse]

A few questions that I hope becomes clear when this actually gets a spec: How do these things re-serialize?

:is(,,,) (do we add spaces at opportune points?)
:host(:is(.a, .b+.c, .d)) (do we keep things that are not parse errors per se, merely disallowed, and do we serialize them back with spaces as if they were fully parsed?)
:has(:is(:has( .x ))) (very similar issue)