Re: [csswg-drafts] [selectors] The forgiving nature of :has breaks jQuery when used with a complex :has selector (#7676)

The CSS Working Group just discussed `[selectors] The forgiving nature of :has breaks jQuery when used with a complex :has selector`, and agreed to the following:

* `RESOLVED: Make has unforgiving`
* `RESOLVED: Limit forgiving behavior to :is and :where and remove it everywhere else`

<details><summary>The full IRC log of that discussion</summary>
&lt;flackr> TabAtkins: since jquery defines :has for internal usage, when you use it in jquery's lib, it tries to evaluate the selector natively. If it throws an error then it goes back and runs custom parser recognizing jquery specific things like what used to be a jquery specific :has<br>
&lt;flackr> TabAtkins: this means putting :has with a jquery specific selector would definitely invoke the jquery parser and get jquery specific behavior<br>
&lt;flackr> TabAtkins: but since we made :has forgiving, if you have a jquery selector inside of :has we drop the jquery specific selector breaking pages depending on previous behavior<br>
&lt;flackr> TabAtkins: couple of proposals. My proposal is to take up fantasai / dbaron proposal to remove forgivingness from :has and everything but the :where and :is pseudoclasses<br>
&lt;flackr> TabAtkins: this will make jquery selectors invalid and fallback to jquery logic<br>
&lt;flackr> TabAtkins: and means the list of things which are forgiving is short and easy to understand<br>
&lt;lea> q?<br>
&lt;flackr> fantasai: :not was made not forgiving intentionally due to strange behavior when you start dropping selectors<br>
&lt;emilio> +1<br>
&lt;flackr> astearns: any concerns with making :has unforgiving?<br>
&lt;flackr> lea: i think it's confusing to have :not not be confusing and :where and :is forgiving<br>
&lt;fantasai> s/be confusing/be forgiving/<br>
&lt;flackr> lea: there has been a proposal to make forgiving selector list invalid if every selector in list is invalid<br>
&lt;flackr> lea: i think this works better regardless of jquery issues<br>
&lt;emilio> q+<br>
&lt;flackr> lea: it does have downsides, e.g. ?? would change the meaning of the selector but that's fixed by putting everything inside the :is<br>
&lt;flackr> lea: I'd be more in favor of this than having some forgiving and others not<br>
&lt;TabAtkins> q+<br>
&lt;flackr> astearns: this could be a separate issue, to continue to extend unforgivingness<br>
&lt;astearns> ack emilio<br>
&lt;flackr> emilio: I find this a bit confusing rather than having is and where being forgiving all the time<br>
&lt;flackr> emilio: browsers may not support some things and then your whole selector gets dropped<br>
&lt;flackr> emilio: I guess you could gate based on number of items, but this breaks the point of making it forgiving<br>
&lt;astearns> ack fantasai<br>
&lt;flackr> fantasai: There are good reasons to make forgivingness not apply to :not, shouldn't go back on this<br>
&lt;flackr> fantasai: i support restricting to :is and :where, it's really simple, and because we do it this way you can control whether something is forgiving or not by wrapping in :is or :where<br>
&lt;flackr> fantasai: i think it gives the author more power to control fallback behavior and is easier to learn<br>
&lt;emilio> +1<br>
&lt;flackr> fantasai: I feel this is easier than having behavior vary<br>
&lt;fantasai> https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1332429146<br>
&lt;flackr> fantasai: my recommendation is take the recommendation TabAtkins proposed ^<br>
&lt;flackr> fantasai: we can take up ?? as a separate item to think about<br>
&lt;astearns> ack TabAtkins<br>
&lt;astearns> s/??/single-item behavior/<br>
&lt;fantasai> s/??/invalidity of a single invalid selector inside :is()//<br>
&lt;flackr> TabAtkins: agree with emilio. I feel strongly we should not make forgivingness predicated on all being invalid or not. It complicates the feature in non-obvious non-predictable ways<br>
&lt;flackr> TabAtkins: they might think something's reasonable but use something that didn't exist. It doesn't seem great to have these gotchas.<br>
&lt;flackr> astearns: let's try to resolve on specific behavior for :has<br>
&lt;flackr> astearns: proposed resolution is to make has unforgiving, any obj?<br>
&lt;flackr> RESOLVED: Make has unforgiving<br>
&lt;flackr> fantasai: can we get a resolution to make everything other than :is and :where unforgiving, e.g. nth-child and nth-last-child<br>
&lt;TabAtkins> +1 to limiting forgivingness to is/where<br>
&lt;flackr> astearns: anyone want to argue for keeping forgiving behavior in any other pseudo?<br>
&lt;flackr> RESOLVED: Limit forgiving behavior to :is and :where and remove it everywhere else<br>
&lt;flackr> astearns: we can discuss limiting it for those in a separate issue<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1341347244 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 7 December 2022 17:52:17 UTC