Selector: Stop relying on CSS.supports( "selector(...)" )
commit68aa2ef7571e2d9f91fad1aa9e5f956c04dc9ee9
authorMichał Gołębiowski-Owczarek <m.goleb@gmail.com>
Tue, 14 Feb 2023 09:11:40 +0000 (14 10:11 +0100)
committerGitHub <noreply@github.com>
Tue, 14 Feb 2023 09:11:40 +0000 (14 10:11 +0100)
tree810ac3b135de06ac113921112f42396759e54147
parent2e644e845051703775b35b358eec5d3608a9465f
Selector: Stop relying on CSS.supports( "selector(...)" )

`CSS.supports( "selector(...)" )` has different semantics than selectors passed
to `querySelectorAll`. Apart from the fact that the former returns `false` for
unrecognized selectors and the latter throws, `qSA` is more forgiving and
accepts some invalid selectors, auto-correcting them where needed - for
example, mismatched brackers are auto-closed. This behavior difference is
breaking for many users.

To add to that, a recent CSSWG resolution made `:is()` & `:where()` the only
pseudos with forgiving parsing; browsers are in the process of making `:has()`
parsing unforgiving.

Taking all that into account, we go back to our previous try-catch approach
without relying on `CSS.supports( "selector(...)" )`. The only difference
is we detect forgiving parsing in `:has()` and mark the selector as buggy.

The PR also updates `playwright-webkit` so that we test against a version
of WebKit that already has non-forgiving `:has()`.

Fixes gh-5194
Closes gh-5206
Ref gh-5098
Ref gh-5107
Ref w3c/csswg-drafts#7676

Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
package.json
src/selector.js
src/selector/rbuggyQSA.js
src/selector/support.js
test/unit/support.js