The fact that the native:has pseudo-class:
https://drafts.csswg.org/selectors/#relational
takesforgiving-relative-selector-list as an argument:
https://drafts.csswg.org/selectors/#forgiving-selector
means the contents are not validated.

jQuery has supported the:has pseudo-class for ages. However, its support is more powerful; in particular, it allows for jQuery extensions like:contains to appear within:has.

The way the jQuery selector engine works (and have worked for a long time), the selector is tried againstquerySelectorAll with minor modifications and if it throws, it goes through the internal selector engine. It's either-or.

Since selectors likeul:has(li:contains('Item')) no longer throw in Chrome, jQuery defers toquerySelectorAll and such a selector returns 0 results even if the jQuery path should match something.

We can of course try to patch it in jQuery, perhaps defaulting selectors containing:has to use the jQuery selector engine. But it won't help countless apps using older jQuery versions. So I wanted to bring it for consideration for the standards committee. I understand if the decision is going to be "no changes in the spec are planned" but it'd be good to have this discussion and the decision made knowing the consequences.

As you can see, it didn't take long after the Chrome 105 release for us to get a bug report about this breakage:
jquery/jquery#5098
Implementing:has according to the spec makes the browser break the jQuery test suite right now.