Forgiving selectors should not be reported as supported with CSS.supports("selector(...)")
Categories
(Core :: DOM: CSS Object Model, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox106 | --- | fixed |
People
(Reporter: mgol, Assigned: emilio)
References
(Blocks 1 open bug)
Details
Attachments
(2 files)
CSS.supports() and @supports should return false for unrecognized selectors in per CSSWG resolution in https://github.com/w3c/csswg-drafts/issues/7280
This bug has been ported from a Chromium one: https://bugs.chromium.org/p/chromium/issues/detail?id=1359396
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.
| Reporter | ||
Updated•3 years ago
|
| Assignee | ||
Comment 1•3 years ago
|
||
Yes, I proposed that change in fact, I just didn't get to fix it just yet :)
| Assignee | ||
Updated•3 years ago
|
| Assignee | ||
Comment 2•3 years ago
|
||
As per spec, see https://github.com/w3c/csswg-drafts/issues/7280
| Assignee | ||
Comment 3•3 years ago
|
||
We've shipped it for a while.
Comment 7•3 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/3e0a5d1881e9
https://hg.mozilla.org/mozilla-central/rev/07d280f89c51
Description
•