Bug 244708 – :has() selector does not accept forgiving selector list

• Status: RESOLVED
• Resolution: INVALID
• Component: CSS

[Rune Lillesveen]

The :has() selector takes a <forgiving-relative-selector-list>[1], but a rule like :has(:unknown) {} is fully dropped in WebKit.

There is a failing wpt test in [2].

[1] https://drafts.csswg.org/selectors/#typedef-forgiving-relative-selector-list
[2] https://wpt.fyi/results/css/selectors/has-error-recovery.html?label=experimental&label=master&aligned

[Michał Gołębiowski-Owczarek]

Note that implementing `:has` according to the spec breaks `:has` usage with jQuery for almost all versions in use in the wild: https://github.com/jquery/jquery/issues/5098

[Antti Koivisto]

We currently do use forgiving parsing for :has() but still fail the selector if the selector lists ends up empty. That is

:has(:foo, bar) { }

is valid and parses to

:has(bar) { }

but 

:has(:foo) is invalid.

[Antti Koivisto]

I suppose this saves us from the jQuery problem.

[Michał Gołębiowski-Owczarek]

See https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1235724730

The WebKit behavior still breaks some jQuery selectors. True, it doesn't break:
```
div:has(span:contains('Item'))
```
but it still breaks:
```
div:has(div, span:contains('Item'))
```
Maybe that latter kind of selectors is not used as often in the wild.

[Michał Gołębiowski-Owczarek]

A full fix for future jQuery versions requires implementing bug 244808 so please have a look at this.

[Radar WebKit Bug Importer]

<rdar://problem/99736653>

[Karl Dubost]

Note that there are discussions about this behavior being beneficial currently, as it doesn't break jQuery.

See the discussion in https://github.com/w3c/csswg-drafts/issues/7676

[Karl Dubost]

oops hit return too early. 
Chrome 106 copies the behavior of Safari.

[Tim Nguyen (:ntim)]

No longer valid with bug 249914.