search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.42k stars 649 forks source link

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

Open cdoublev opened 1 year ago

cdoublev commented 1 year ago

It has been resolved to disable forgiving parsing in selector(). 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>.

Outdated browser interoperability issue Chrome and FF seem to disagree on forgiving invalid selectors in `selector()`: in the following test case, `text` is red, not underlined in Chrome, and is neither red or underlined in FF. ```html
text
``` Also, should `selector(:is())` evaluate to `true` or `false`? Chrome and FF also disagree on this.

I do not have a strong opinion but I find it a bit surprising that selector(:is(::before, div)) must evaluate to false whereas :is(::before, div) selects any div. If the author wants to test the support of pseudo-elements, he can write selector(::pseudo) or selector(:not(::pseudo, ::another-pseudo)).

myakura commented 1 year ago

Chrome and FF seem to disagree on forgiving invalid selectors in selector()

Isn't that because Chrome hasn't landed unforgiving parsing in selector() yet? https://groups.google.com/a/chromium.org/g/blink-dev/c/RJrIxJA9LYw

With the Experimental Web Platform features flag enabled in Canary, I see the test matches Firefox.

cdoublev commented 1 year ago

Ok, I only checked the browser compat table.

I am fine with unforgiving parsing (minus the observation in my previous comment) but the related note (quoted below) seems a bit handwavy to justify evaluating selector(:is()) to false:

Note: Some functional selectors are parsed forgivingly, i.e. if some arguments are unknown/invalid, the selector itself is not invalidated. These are nonetheless unsupported

Resolving to false means that :is() take <selector-list> (list cannot be empty) instead of <forgiving-selector-list> (list can be empty). I mean, this is not a context rule applying on the result of <forgiving-selector-list>, whereas restrictions apply when pseudo-classing a pseudo-element, for example.