Re: [csswg-drafts] [selectors] [css-conditional] Detecting :has() restrictions (#7280)

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`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> Topic:  [selectors] [css-conditional] Detecting :has() restrictions<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/7280<br>
&lt;fantasai> emilio: It seems this is not going to have so many restrictions, so maybe not a big deal<br>
&lt;fantasai> emilio: In case we wanted to restrict stuff like :host<br>
&lt;fantasai> emilio: and then eventually potentially ...<br>
&lt;fantasai> emilio: not easy to detect which UAs would support it vs not<br>
&lt;fantasai> emilio: since :has() uses forgiving parsing, anything you throw at it is valid<br>
&lt;fantasai> emilio: It seems we're only going to restrict :has() inside :has()<br>
&lt;fantasai> emilio: doesn't seem useful but complex, but may still matter...<br>
&lt;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<br>
&lt;jensimmons> +1000<br>
&lt;fantasai> emilio: If you put @supports :has(:has()) ...<br>
&lt;fantasai> emilio: makes it a problem if you want to do something in the future<br>
&lt;jensimmons> =Q<br>
&lt;jensimmons> +q<br>
&lt;fantasai> emilio: you can always test the thing inside<br>
&lt;fantasai> TabAtkins: not true<br>
&lt;fantasai> TabAtkins: :is()-disallowed pseudo-elements, for example<br>
&lt;fantasai> TabAtkins: this sounds reasonable to me<br>
&lt;fantasai> TabAtkins: unsure about forgiving vs unforgiving<br>
&lt;astearns> ack jensimmons<br>
&lt;fantasai> jensimmons: I think it's a really good idea<br>
&lt;oriol> q+<br>
&lt;fantasai> jensimmons: Having @supports parse as valid a thing that the browser doesn't support<br>
&lt;fantasai> jensimmons: for the future, we need @supports to be accurate and true<br>
&lt;fantasai> emilio: For FF it's easy, just passing down a flag<br>
&lt;astearns> ack oriol<br>
&lt;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<br>
&lt;fantasai> oriol: It would be something like, if you have some invalid and some valid treat whole as invalid<br>
&lt;fantasai> oriol: So if you only have invalid ones, it would be invalid. If you have a mix, it would be valid<br>
&lt;emilio> oriol is saying that `:has(:random)` would be valid, but `:has(something, :random)` would be valid<br>
&lt;astearns> s/whole as invalid/whole as valid/<br>
&lt;fantasai> oriol: So if using :has(invalid) then is invalid, and detect that without having to make supports change the syntax<br>
&lt;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<br>
&lt;fantasai> emilio: Some precedent here wrt -webkit- stuff<br>
&lt;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<br>
&lt;fantasai> emilio: Especially if CSS author, unlikely to jump to using JS to check<br>
&lt;fantasai> astearns: So proposed resolution is for @supports to use non-forgiving parsing for all selectors<br>
&lt;fantasai> TabAtkins: yes<br>
&lt;fantasai> strong +1<br>
&lt;fantasai> RESOLVED: @supports uses non-forgiving parsing for all selectors<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7280#issuecomment-1143852187 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 1 June 2022 16:34:42 UTC