Selector: Use jQuery `:has` if `CSS.supports(selector(...))` non-compliant by mgol · Pull Request #5107 · jquery/jquery

mgol · 2022-09-05T14:03:10Z

Summary

jQuery has followed the following logic for selector handling for ages:

Modify the selector to adhere to scoping rules jQuery mandates.
Try qSA on the modified selector. If it succeeds, use the results.
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:

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:

In browsers supports the new spec change to CSS.supports( "selector()" ),
use it before trying qSA.
Otherwise, add :has to the buggy selectors list.

Fixes gh-5098

+118 bytes but +93 out of that is this new mechanism using CSS.supports( "selector()" ) which we have to add anyway due to what I described above. Of course, suggestions on how to reduce that welcome.

A backport of that to Sizzle will be required once this PR is accepted.

Checklist

New tests have been added to show the fix or feature works
Grunt build and unit tests pass locally with these changes
~~If needed, a docs issue/PR was created at https://github.com/jquery/api.jquery.com~~

mgol · 2022-09-05T15:42:15Z

Chrome 105 is not available in GitHub Actions yet but I checked locally that all tests are passing there.

The failure was caused by incorrect usage of self-closing tags, incompatible with jQuery 3.5.0+. As of this commit, all tests pass in Firefox 104.0.2 and almost all in Chrome 105.0.5195.102 - with the exception of ones fixed in jquerygh-5107. From Sizzle tests run on `jQuery.find`, apart from the above, there are still two failures in both these browsers: * `selector: id`: ID Selector on Form with an input that has a name of 'id' (#lengthtest) * `utilities: Sizzle.uniqueSort`: Attached/detached mixture (array) & Attached/detached mixture (quasi-array)

mgol · 2022-09-09T17:37:03Z

Oh, tests already run on Chrome 105 in this PR. That confirms the fix works.

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

mgol · 2022-09-11T22:20:39Z

Sizzle version of this PR, meant for jQuery 3.6.2: jquery/sizzle#486

The failure was caused by incorrect usage of self-closing tags, incompatible with jQuery 3.5.0+. As of this commit, all tests pass in Firefox 104.0.2 and almost all in Chrome 105.0.5195.102 - with the exception of ones fixed in jquerygh-5107. From Sizzle tests run on `jQuery.find`, apart from the above, there are still two failures in both these browsers: * `selector: id`: ID Selector on Form with an input that has a name of 'id' (#lengthtest) * `utilities: Sizzle.uniqueSort`: Attached/detached mixture (array) & Attached/detached mixture (quasi-array)

mgol · 2022-09-15T10:50:05Z

src/selector.js

+						// eslint-disable-next-line no-undef
+						!CSS.supports( "selector(" + newSelector + ")" ) ) {
+
+						// Support: IE 11+


This is actually not just targeted at IE but at all browsers where CSS.supports is buggy. I should update the comment.

timmywil

LGTM!

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

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

…liant 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 Closes gh-486 Ref jquery/jquery#5107 Ref w3c/csswg-drafts#7676

The failure was caused by incorrect usage of self-closing tags, incompatible with jQuery 3.5.0+. As of this commit, all tests pass in Firefox 104.0.2 and almost all in Chrome 105.0.5195.102 - with the exception of ones fixed in jquerygh-5107. From Sizzle tests run on `jQuery.find`, apart from the above, there are still two failures in both these browsers: * `selector: id`: ID Selector on Form with an input that has a name of 'id' (#lengthtest) * `utilities: Sizzle.uniqueSort`: Attached/detached mixture (array) & Attached/detached mixture (quasi-array)

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

The failure was caused by incorrect usage of self-closing tags, incompatible with jQuery 3.5.0+. As of this commit, all tests pass in Firefox 104.0.2 and almost all in Chrome 105.0.5195.102 - with the exception of ones fixed in jquerygh-5107. From Sizzle tests run on `jQuery.find`, apart from the above, there are still two failures in both these browsers: * `selector: id`: ID Selector on Form with an input that has a name of 'id' (#lengthtest) * `utilities: Sizzle.uniqueSort`: Attached/detached mixture (array) & Attached/detached mixture (quasi-array)

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

The failure was caused by incorrect usage of self-closing tags, incompatible with jQuery 3.5.0+. As of this commit, all tests pass in Firefox 104.0.2 and almost all in Chrome 105.0.5195.102 - with the exception of ones fixed in jquerygh-5107. From Sizzle tests run on `jQuery.find`, apart from the above, there are still two failures in both these browsers: * `selector: id`: ID Selector on Form with an input that has a name of 'id' (#lengthtest) * `utilities: Sizzle.uniqueSort`: Attached/detached mixture (array) & Attached/detached mixture (quasi-array)

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

Fixes jquerygh-5098 Ref jquery/sizzle#486 Ref jquerygh-5107

Fixes gh-5098 Closes gh-5135 Ref jquery/sizzle#486 Ref gh-5107