diff options
author | Michał Gołębiowski-Owczarek <m.goleb@gmail.com> | 2023-02-14 10:11:40 +0100 |
---|---|---|
committer | GitHub <noreply@github.com> | 2023-02-14 10:11:40 +0100 |
commit | 68aa2ef7571e2d9f91fad1aa9e5f956c04dc9ee9 (patch) | |
tree | 810ac3b135de06ac113921112f42396759e54147 /src/selector/support.js | |
parent | 2e644e845051703775b35b358eec5d3608a9465f (diff) | |
download | jquery-68aa2ef7571e2d9f91fad1aa9e5f956c04dc9ee9.tar.gz jquery-68aa2ef7571e2d9f91fad1aa9e5f956c04dc9ee9.zip |
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>
Diffstat (limited to 'src/selector/support.js')
-rw-r--r-- | src/selector/support.js | 33 |
1 files changed, 13 insertions, 20 deletions
diff --git a/src/selector/support.js b/src/selector/support.js index 387c41bfe..396e0e046 100644 --- a/src/selector/support.js +++ b/src/selector/support.js @@ -1,27 +1,20 @@ +import document from "../var/document.js"; import support from "../var/support.js"; -// Support: IE 11+ -// IE doesn't support `CSS.supports( "selector(...)" )`; it will throw -// in this support test. +// Support: Chrome 105 - 110+, Safari 15.4 - 16.3+ +// Make sure the the `:has()` argument is parsed unforgivingly. +// We include `*` in the test to detect buggy implementations that are +// _selectively_ forgiving (specifically when the list includes at least +// one valid selector). +// Note that we treat complete lack of support for `:has()` as if it were +// spec-compliant support, which is fine because use of `:has()` in such +// environments will fail in the qSA path and fall back to jQuery traversal +// anyway. try { - /* eslint-disable no-undef */ - - // Support: Chrome 105+, Firefox <106, Safari 15.4+ - // Make sure forgiving mode is not used in `CSS.supports( "selector(...)" )`. - // - // `:is()` uses a forgiving selector list as an argument and is widely - // implemented, so it's a good one to test against. - support.cssSupportsSelector = CSS.supports( "selector(*)" ) && - - // `*` is needed as Safari & newer Chrome implemented something in between - // for `:has()` - it throws in `qSA` if it only contains an unsupported - // argument but multiple ones, one of which is supported, are fine. - // We want to play safe in case `:is()` gets the same treatment. - !CSS.supports( "selector(:is(*,:jqfake))" ); - - /* eslint-enable */ + document.querySelector( ":has(*,:jqfake)" ); + support.cssHas = false; } catch ( e ) { - support.cssSupportsSelector = false; + support.cssHas = true; } export default support; |