Selector: Use Sizzle :has if CSS.supports(selector(...)) non-compliant#486
Merged
mgol merged 1 commit intojquery:mainfrom Sep 19, 2022
Merged
Selector: Use Sizzle :has if CSS.supports(selector(...)) non-compliant#486mgol merged 1 commit intojquery:mainfrom
:has if CSS.supports(selector(...)) non-compliant#486mgol merged 1 commit intojquery:mainfrom
Conversation
2 tasks
Member
Author
|
jQuery version of this PR for jQuery 4.0.0: jquery/jquery#5107 |
Member
Author
|
I run tests on this PR with a CP from #485 locally on the same browsers on which they're run on CI and all passed. |
mgol
commented
Sep 12, 2022
| elem.type === "text" && | ||
|
|
||
| // Support: IE<8 | ||
| // Support: IE <10 only |
Member
Author
There was a problem hiding this comment.
This change is not related but I found it while working on jquery/jquery#5113 and discovering removal of this workaround breaks the relevant test in IE 9.
7 tasks
mgol
commented
Sep 15, 2022
| !el.querySelectorAll( ":scope fieldset div" ).length; | ||
| } ); | ||
|
|
||
| // Support: Chrome 105+, Firefox 104+, Safari 15.4+ |
Member
Author
There was a problem hiding this comment.
Suggested change
| // Support: Chrome 105+, Firefox 104+, Safari 15.4+ | |
| // Support: Chrome 105+, Firefox 104+, Safari 15.4+, IE 6 - 11+, Edge 12 - 18+ |
Plus, I should mention IE & Edge as ones not supporting the API at all.
mgol
changed the title
CSS.supports(selector(...)) non-compliant:has if CSS.supports(selector(...)) non-compliant
timmywil
approved these changes
Sep 19, 2022
Member
timmywil
left a comment
timmywil
left a comment
There was a problem hiding this comment.
Good use of CSS.supports with :is!
mgol
force-pushed
the
css-supports-has
branch
from
90ae0cd to
50a1a1b
Compare
Sizzle has followed the following logic for selector handling for ages:
1. Modify the selector to adhere to scoping rules jQuery mandates.
2. Try `qSA` on the modified selector. If it succeeds, use the results.
3. If `qSA` threw an error, run the Sizzle custom traversal instead.
It worked fine so far but now CSS has a concept of forgiving selector lists that
some selectors like `:is()` & `:has()` use. That means providing unrecognized
selectors as parameters to `:is()` & `:has()` no longer throws an error, it will
just return no results. That made browsers with native `:has()` support break
selectors using jQuery extensions inside, e.g. `:has(:contains("Item"))`.
Detecting support for selectors can also be done via:
```js
CSS.supports( "selector(SELECTOR_TO_BE_TESTED)" )
```
which returns a boolean. There was a recent spec change requiring this API to
always use non-forgiving parsing:
w3c/csswg-drafts#7280 (comment)
However, no browsers have implemented this change so far.
To solve this, two changes are being made:
1. In browsers supports the new spec change to `CSS.supports( "selector()" )`,
use it before trying `qSA`.
2. Otherwise, add `:has` to the buggy selectors list.
Fixes jquery/jquery#5098
Ref jquery/jquery#5107
Ref w3c/csswg-drafts#7676
mgol
force-pushed
the
css-supports-has
branch
from
50a1a1b to
2e276d4
Compare
mgol
added a commit
to mgol/jquery
that referenced
this pull request
Sep 21, 2022
jQuery has followed the following logic for selector handling for ages:
1. Modify the selector to adhere to scoping rules jQuery mandates.
2. Try `qSA` on the modified selector. If it succeeds, use the results.
3. If `qSA` threw an error, run the jQuery custom traversal instead.
It worked fine so far but now CSS has a concept of forgiving selector lists that
some selectors like `:is()` & `:has()` use. That means providing unrecognized
selectors as parameters to `:is()` & `:has()` no longer throws an error, it will
just return no results. That made browsers with native `:has()` support break
selectors using jQuery extensions inside, e.g. `:has(:contains("Item"))`.
Detecting support for selectors can also be done via:
```js
CSS.supports( "selector(SELECTOR_TO_BE_TESTED)" )
```
which returns a boolean. There was a recent spec change requiring this API to
always use non-forgiving parsing:
w3c/csswg-drafts#7280 (comment)
However, no browsers have implemented this change so far.
To solve this, two changes are being made:
1. In browsers supports the new spec change to `CSS.supports( "selector()" )`,
use it before trying `qSA`.
2. Otherwise, add `:has` to the buggy selectors list.
Ref jquerygh-5098
Ref jquerygh-5107
Ref jquery/sizzle#486
Ref w3c/csswg-drafts#7676
mgol
added a commit
to mgol/jquery
that referenced
this pull request
Sep 21, 2022
jQuery has followed the following logic for selector handling for ages:
1. Modify the selector to adhere to scoping rules jQuery mandates.
2. Try `qSA` on the modified selector. If it succeeds, use the results.
3. If `qSA` threw an error, run the jQuery custom traversal instead.
It worked fine so far but now CSS has a concept of forgiving selector lists that
some selectors like `:is()` & `:has()` use. That means providing unrecognized
selectors as parameters to `:is()` & `:has()` no longer throws an error, it will
just return no results. That made browsers with native `:has()` support break
selectors using jQuery extensions inside, e.g. `:has(:contains("Item"))`.
Detecting support for selectors can also be done via:
```js
CSS.supports( "selector(SELECTOR_TO_BE_TESTED)" )
```
which returns a boolean. There was a recent spec change requiring this API to
always use non-forgiving parsing:
w3c/csswg-drafts#7280 (comment)
However, no browsers have implemented this change so far.
To solve this, two changes are being made:
1. In browsers supports the new spec change to `CSS.supports( "selector()" )`,
use it before trying `qSA`.
2. Otherwise, add `:has` to the buggy selectors list.
Ref jquerygh-5098
Ref jquerygh-5107
Ref jquery/sizzle#486
Ref w3c/csswg-drafts#7676
mgol
added a commit
to mgol/jquery
that referenced
this pull request
Oct 3, 2022
jQuery has followed the following logic for selector handling for ages:
1. Modify the selector to adhere to scoping rules jQuery mandates.
2. Try `qSA` on the modified selector. If it succeeds, use the results.
3. If `qSA` threw an error, run the jQuery custom traversal instead.
It worked fine so far but now CSS has a concept of forgiving selector lists that
some selectors like `:is()` & `:has()` use. That means providing unrecognized
selectors as parameters to `:is()` & `:has()` no longer throws an error, it will
just return no results. That made browsers with native `:has()` support break
selectors using jQuery extensions inside, e.g. `:has(:contains("Item"))`.
Detecting support for selectors can also be done via:
```js
CSS.supports( "selector(SELECTOR_TO_BE_TESTED)" )
```
which returns a boolean. There was a recent spec change requiring this API to
always use non-forgiving parsing:
w3c/csswg-drafts#7280 (comment)
However, no browsers have implemented this change so far.
To solve this, two changes are being made:
1. In browsers supports the new spec change to `CSS.supports( "selector()" )`,
use it before trying `qSA`.
2. Otherwise, add `:has` to the buggy selectors list.
Ref jquerygh-5098
Ref jquerygh-5107
Ref jquery/sizzle#486
Ref w3c/csswg-drafts#7676
mgol
added a commit
to mgol/jquery
that referenced
this pull request
Oct 3, 2022
mgol
added a commit
to mgol/jquery
that referenced
this pull request
Oct 3, 2022
1 task
mgol
added a commit
to jquery/jquery
that referenced
this pull request
Oct 4, 2022
Fixes gh-5098 Closes gh-5135 Ref jquery/sizzle#486 Ref gh-5107
mgol
added a commit
to mgol/jquery
that referenced
this pull request
Oct 4, 2022
jQuery has followed the following logic for selector handling for ages:
1. Modify the selector to adhere to scoping rules jQuery mandates.
2. Try `qSA` on the modified selector. If it succeeds, use the results.
3. If `qSA` threw an error, run the jQuery custom traversal instead.
It worked fine so far but now CSS has a concept of forgiving selector lists that
some selectors like `:is()` & `:has()` use. That means providing unrecognized
selectors as parameters to `:is()` & `:has()` no longer throws an error, it will
just return no results. That made browsers with native `:has()` support break
selectors using jQuery extensions inside, e.g. `:has(:contains("Item"))`.
Detecting support for selectors can also be done via:
```js
CSS.supports( "selector(SELECTOR_TO_BE_TESTED)" )
```
which returns a boolean. There was a recent spec change requiring this API to
always use non-forgiving parsing:
w3c/csswg-drafts#7280 (comment)
However, no browsers have implemented this change so far.
To solve this, two changes are being made:
1. In browsers supports the new spec change to `CSS.supports( "selector()" )`,
use it before trying `qSA`.
2. Otherwise, add `:has` to the buggy selectors list.
Ref jquerygh-5098
Ref jquerygh-5107
Ref jquery/sizzle#486
Ref w3c/csswg-drafts#7676
mgol
added a commit
to mgol/jquery
that referenced
this pull request
Nov 17, 2022
jQuery has followed the following logic for selector handling for ages:
1. Modify the selector to adhere to scoping rules jQuery mandates.
2. Try `qSA` on the modified selector. If it succeeds, use the results.
3. If `qSA` threw an error, run the jQuery custom traversal instead.
It worked fine so far but now CSS has a concept of forgiving selector lists that
some selectors like `:is()` & `:has()` use. That means providing unrecognized
selectors as parameters to `:is()` & `:has()` no longer throws an error, it will
just return no results. That made browsers with native `:has()` support break
selectors using jQuery extensions inside, e.g. `:has(:contains("Item"))`.
Detecting support for selectors can also be done via:
```js
CSS.supports( "selector(SELECTOR_TO_BE_TESTED)" )
```
which returns a boolean. There was a recent spec change requiring this API to
always use non-forgiving parsing:
w3c/csswg-drafts#7280 (comment)
However, no browsers have implemented this change so far.
To solve this, two changes are being made:
1. In browsers supports the new spec change to `CSS.supports( "selector()" )`,
use it before trying `qSA`.
2. Otherwise, add `:has` to the buggy selectors list.
Ref jquerygh-5098
Ref jquerygh-5107
Ref jquery/sizzle#486
Ref w3c/csswg-drafts#7676
mgol
added a commit
to mgol/jquery
that referenced
this pull request
Dec 1, 2022
jQuery has followed the following logic for selector handling for ages:
1. Modify the selector to adhere to scoping rules jQuery mandates.
2. Try `qSA` on the modified selector. If it succeeds, use the results.
3. If `qSA` threw an error, run the jQuery custom traversal instead.
It worked fine so far but now CSS has a concept of forgiving selector lists that
some selectors like `:is()` & `:has()` use. That means providing unrecognized
selectors as parameters to `:is()` & `:has()` no longer throws an error, it will
just return no results. That made browsers with native `:has()` support break
selectors using jQuery extensions inside, e.g. `:has(:contains("Item"))`.
Detecting support for selectors can also be done via:
```js
CSS.supports( "selector(SELECTOR_TO_BE_TESTED)" )
```
which returns a boolean. There was a recent spec change requiring this API to
always use non-forgiving parsing:
w3c/csswg-drafts#7280 (comment)
However, no browsers have implemented this change so far.
To solve this, two changes are being made:
1. In browsers supports the new spec change to `CSS.supports( "selector()" )`,
use it before trying `qSA`.
2. Otherwise, add `:has` to the buggy selectors list.
Ref jquerygh-5098
Ref jquerygh-5107
Ref jquery/sizzle#486
Ref w3c/csswg-drafts#7676
mgol
added a commit
to mgol/jquery
that referenced
this pull request
Dec 13, 2022
jQuery has followed the following logic for selector handling for ages:
1. Modify the selector to adhere to scoping rules jQuery mandates.
2. Try `qSA` on the modified selector. If it succeeds, use the results.
3. If `qSA` threw an error, run the jQuery custom traversal instead.
It worked fine so far but now CSS has a concept of forgiving selector lists that
some selectors like `:is()` & `:has()` use. That means providing unrecognized
selectors as parameters to `:is()` & `:has()` no longer throws an error, it will
just return no results. That made browsers with native `:has()` support break
selectors using jQuery extensions inside, e.g. `:has(:contains("Item"))`.
Detecting support for selectors can also be done via:
```js
CSS.supports( "selector(SELECTOR_TO_BE_TESTED)" )
```
which returns a boolean. There was a recent spec change requiring this API to
always use non-forgiving parsing:
w3c/csswg-drafts#7280 (comment)
However, no browsers have implemented this change so far.
To solve this, two changes are being made:
1. In browsers supports the new spec change to `CSS.supports( "selector()" )`,
use it before trying `qSA`.
2. Otherwise, add `:has` to the buggy selectors list.
Ref jquerygh-5098
Ref jquerygh-5107
Ref jquery/sizzle#486
Ref w3c/csswg-drafts#7676
mgol
added a commit
to mgol/sizzle
that referenced
this pull request
Feb 10, 2023
`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. Fixes jquery/jquery#5194 Ref jquery/jquery#5098 Ref jquerygh-486 Ref w3c/csswg-drafts#7676
mgol
added a commit
to mgol/sizzle
that referenced
this pull request
Feb 13, 2023
`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. Fixes jquery/jquery#5194 Ref jquery/jquery#5098 Ref jquerygh-486 Ref w3c/csswg-drafts#7676
mgol
added a commit
that referenced
this pull request
Feb 14, 2023
`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. Fixes jquery/jquery#5194 Closes gh-493 Ref jquery/jquery#5098 Ref jquery/jquery#5206 Ref jquery/jquery#5207 Ref gh-486 Ref w3c/csswg-drafts#7676
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sizzle has followed the following logic for selector handling for ages:
qSAon the modified selector. If it succeeds, use the results.qSAthrew an error, run the Sizzle custom traversal instead.It worked fine so far but now CSS has a concept of forgiving selector lists that some selectors like
:is()&:has()use. That means providing unrecognized selectors as parameters to:is()&:has()no longer throws an error, it will just return no results. That made browsers with native:has()support break selectors using jQuery extensions inside, e.g.:has(:contains("Item")).Detecting support for selectors can also be done via:
which returns a boolean. There was a recent spec change requiring this API to always use non-forgiving parsing:
w3c/csswg-drafts#7280 (comment) However, no browsers have implemented this change so far.
To solve this, two changes are being made:
CSS.supports( "selector()" ), use it before tryingqSA.:hasto the buggy selectors list.Fixes jquery/jquery#5098
Ref jquery/jquery#5107
+78 bytes