[csswg-drafts] [css-conditional-4] Reconsider disabling unforgiving parsing in `selector()` (#8295)

cdoublev has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-conditional-4] Reconsider disabling unforgiving parsing in `selector()` ==
It has been [resolved](https://github.com/w3c/csswg-drafts/issues/7280#issuecomment-1143852187) to disable forgiving parsing in [`selector()`](https://w3c.github.io/csswg-drafts/css-conditional-4/#typedef-supports-selector-fn). The initial motivation was to add styles based on user agent restrictions on `:has()` argument, which was previously `<forgiving-relative-selector-list>` but is now `<relative-selector-list>`.

Chrome and FF seem to disagree on forgiving invalid selectors in `selector()`: in the following test case, `text` is red and not underlined in Chrome, and is neither red or underlined in FF.

```html
<style>
  @supports selector(:is(undeclared|div)) { /* Forgiving :is() */
    div { color: red }
  }
  @supports selector(:not(undeclared|div)) { /* Unforgiving :not() */
    div { text-decoration: underline }
  }
</style>
<div>text</div>
```

I do not have a strong opinion but I find it a bit surprising that `selector(:is(::before, div))` would be evaluated `false` whereas `:is(::before, div)` would selector any `div`. If the author wants to test the support of pseudo-elements in logical combinations, it can write `selector(:not(::pseudo))`.

Also, should `selector(:is())` evaluate to `true` or `false`? (cf. https://github.com/w3c/csswg-drafts/issues/2352#issuecomment-1330767025)

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8295 using your GitHub account


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

Received on Tuesday, 10 January 2023 06:41:15 UTC