RESOLVED FIXED 244808
Forgiving selectors should not be reported as supported with CSS.supports("selector(...)")
https://bugs.webkit.org/show_bug.cgi?id=244808
Summary Forgiving selectors should not be reported as supported with CSS.supports("se...
Michał Gołębiowski-Owczarek
Reported 2022-09-05 05:51:29 PDT
CSS.supports() and @supports should return false for unrecognized selectors in per CSSWG resolution in https://github.com/w3c/csswg-drafts/issues/7280 For why this matters for jQuery, see this comment: https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1235714917 and that whole issue in general. tl;dr is that jQuery has custom selector extensions but for performance reasons it first tries to run a provided selector through `querySelectorAll` and only when that fails it uses its own custom DOM traversal. However, this approach doesn't work for pseudo-classes using forgiving selector lists as parameters - like `:has()`. jQuery would like to migrate to testing the selector via `CSS.supports("selector(...)")` instead but right now it returns `true` for `:has(:gibberish)` as well. The linked CSS WG resolution makes the API return `false` in such cases, making it a viable tool for jQuery. Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1359396 Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1789248
Attachments
Patch (37.86 KB, patch)
2022-09-14 06:53 PDT, Antti Koivisto
no flags
Radar WebKit Bug Importer
Comment 2 2022-09-07 22:57:12 PDT
Antti Koivisto
Comment 3 2022-09-14 06:53:26 PDT
EWS
Comment 4 2022-09-14 12:49:03 PDT
Committed 254489@main (fc2b16c5035f): <https://commits.webkit.org/254489@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 462332 [details].
Note You need to log in before you can comment on or make changes to this bug.