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)

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

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)

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 jquerygh-5098
Ref jquery/sizzle#486
Ref jquerygh-5107

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

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

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

`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 jquerygh-5194
Ref jquerygh-5098
Ref jquerygh-5107
Ref w3c/csswg-drafts#7676

`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 jquerygh-5194
Ref jquerygh-5098
Ref jquerygh-5107
Ref w3c/csswg-drafts#7676

`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 jquerygh-5194
Ref jquerygh-5098
Ref jquerygh-5107
Ref w3c/csswg-drafts#7676

`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 jquerygh-5194
Ref jquerygh-5098
Ref jquerygh-5107
Ref w3c/csswg-drafts#7676

`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 jquerygh-5194
Ref jquerygh-5098
Ref jquerygh-5107
Ref w3c/csswg-drafts#7676

`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>

`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-5207
Ref gh-5206
Ref gh-5098
Ref gh-5107
Ref w3c/csswg-drafts#7676