[selectors] [css-conditional] Detecting :has() restrictions

[emilio]

Multiple implementations want to ship the :has() selector with a variety of limitations in order to prevent performance footguns and complexity:

• [selectors-4] Remove the :scope dependency from the relative selectors definition #6399
• [selectors-4] Consider disallowing logical combination pseudo-classes inside :has() #6952
• [selectors-4] Consider disallowing :scope inside :has() #7211
• [selectors-4] Consider disallowing :host, :host(), :host-context() inside :has() #7212

However, since :has() has forgiving parsing like :is() / :where(), it's not possible to detect these limitations easily, and it won't be possible to do so if we ever remove these limitations.

For :is() / :where() it's not a problem since it's generally assumed that if the selector is valid outside of them it'll be valid inside of them... But for the limitations that folks are imposing on :has() (and which for the record I agree with) this is not true.

Perhaps we should special-case @supports selector(..) to not use forgiving parsing? Otherwise the only way to potentially detect this is with script (by reading back the serialization of :has() and see if the relevant selectors have been dropped).

cc @byung-woo @anttijk

[byung-woo]

Perhaps we should special-case @supports selector(..) to not use forgiving parsing?

I think this is a good way to detect the limitations without losing the benefits of forgiving parsing.

Currently, pseudo-elements are explicitly disallowed inside :is() (https://drafts.csswg.org/selectors-4/#matches).

If @supports can detect the limitation inside logical combinations, I think we can provide more clear limitation by wpt, something like:

@supports not selector(:is(::first-letter)) {
 #disallow_first_letter_inside_is { color: green }
}
@supports not selector(:has(:host)) {
 #disallow_host_inside_has { color: green }
}

How about others?

[css-meeting-bot]

The CSS Working Group just discussed [selectors] [css-conditional] Detecting :has() restrictions, and agreed to the following:

• RESOLVED: @supports uses non-forgiving parsing for all selectors

The full IRC log of that discussion

<fantasai> Topic: [selectors] [css-conditional] Detecting :has() restrictions
<fantasai> github: https://github.com//issues/7280
<fantasai> emilio: It seems this is not going to have so many restrictions, so maybe not a big deal
<fantasai> emilio: In case we wanted to restrict stuff like :host
<fantasai> emilio: and then eventually potentially ...
<fantasai> emilio: not easy to detect which UAs would support it vs not
<fantasai> emilio: since :has() uses forgiving parsing, anything you throw at it is valid
<fantasai> emilio: It seems we're only going to restrict :has() inside :has()
<fantasai> emilio: doesn't seem useful but complex, but may still matter...
<fantasai> emilio: My point is that if we have any hope for unrestricting, it may be useful to be able to detect it when we do
<jensimmons> +1000
<fantasai> emilio: If you put @supports :has(:has()) ...
<fantasai> emilio: makes it a problem if you want to do something in the future
<jensimmons> =Q
<jensimmons> +q
<fantasai> emilio: you can always test the thing inside
<fantasai> TabAtkins: not true
<fantasai> TabAtkins: :is()-disallowed pseudo-elements, for example
<fantasai> TabAtkins: this sounds reasonable to me
<fantasai> TabAtkins: unsure about forgiving vs unforgiving
<astearns> ack jensimmons
<fantasai> jensimmons: I think it's a really good idea
<oriol> q+
<fantasai> jensimmons: Having @supports parse as valid a thing that the browser doesn't support
<fantasai> jensimmons: for the future, we need @supports to be accurate and true
<fantasai> emilio: For FF it's easy, just passing down a flag
<astearns> ack oriol
<fantasai> oriol: I wonder if rather than adding hack in supports we could say that if you have either :has() or whatever that has this forgiving syntax, and all of the selectors inside it are invalid, then it would also be invalid
<fantasai> oriol: It would be something like, if you have some invalid and some valid treat whole as invalid
<fantasai> oriol: So if you only have invalid ones, it would be invalid. If you have a mix, it would be valid
<emilio> oriol is saying that `:has(:random)` would be valid, but `:has(something, :random)` would be valid
<astearns> s/whole as invalid/whole as valid/
<fantasai> oriol: So if using :has(invalid) then is invalid, and detect that without having to make supports change the syntax
<fantasai> fantasai: OK, so I'm with jensimmons here. If the selector contains anything invalid, then it should return as invalid even if the invalidity is caught at a lower level
<fantasai> emilio: Some precedent here wrt -webkit- stuff
<fantasai> jensimmons: If this occurred to me as a developer, I wouldn't look it up. I would use @supports to detect support, e.g with color:red
<fantasai> emilio: Especially if CSS author, unlikely to jump to using JS to check
<fantasai> astearns: So proposed resolution is for @supports to use non-forgiving parsing for all selectors
<fantasai> TabAtkins: yes
<fantasai> strong +1
<fantasai> RESOLVED: @supports uses non-forgiving parsing for all selectors

[svgeesus]

It looks like this would affect at-supports-046.html which assumes forgiving parsing? (wpt results)

[fantasai]

@svgeesus No, that test is fine. This is about the contents of the selector() function.