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 `forgiving nature of :has()`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: forgiving nature of :has()<br>
&lt;TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/7676<br>
&lt;TabAtkins> TabAtkins: i think we've lost enough people that are relevant to this<br>
&lt;TabAtkins> emilio: i have an opinion, but...<br>
&lt;TabAtkins> emilio: tldr is Chrome shipped :has() with forgiving parsing, bc jQuery calls querySelector() and if it throws, use their custom selector parser<br>
&lt;TabAtkins> emilio: i filed an issue a while ago about makign @support selector() not be forgiving, which lets jQuery do the right thing here, but that doesn't fix existing usage<br>
&lt;emilio> https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1235773031<br>
&lt;TabAtkins> emilio: 1) rename :has(), which isn't great<br>
&lt;TabAtkins> emilio: 2) give up on forgiving-selector-list, which also isn't great. is()/:where() already shipped with it<br>
&lt;TabAtkins> emilio: 2.5) give up on forgiving-selector-list in :has() specifically<br>
&lt;TabAtkins> Sorry, misminuted<br>
&lt;TabAtkins> emilio: 2.5) spec the webkit bug, which is unforgiving if *all* of the selectors fail<br>
&lt;TabAtkins> fremy: another idea is to explicitly check the jquery pseudoclasses and poison them<br>
&lt;fantasai> -1 to special-casing jquery<br>
&lt;TabAtkins> emilio: there's a lot, plus jquery just has some different parsing for the matching stuff of us, too<br>
&lt;TabAtkins> emilio: 3) leave it; if breakage isn't too big, oh well<br>
&lt;TabAtkins> fantasai: I'm okay with saying :has() is unforgiving, you can nest an :is() if you want<br>
&lt;TabAtkins> fantasai: lets authors be strict if they want<br>
&lt;fantasai> TabAtkins: We're not entirely consistent. :not() is unforgiving, for example<br>
&lt;andreubotella> q-<br>
&lt;astearns> ack andreubotella<br>
&lt;astearns> ack dbaron<br>
&lt;TabAtkins> dbaron: two thoughts, both weak prefs<br>
&lt;TabAtkins> dbaron: ONe is, I have mixed feelings about fogiving-selector-list<br>
&lt;TabAtkins> dbaron: even if the group thinks the old selector parsing is a mistake, having two models used in different places is worse than having just the bad one<br>
&lt;TabAtkins> dbaron: in terms of author confusion<br>
&lt;TabAtkins> dbaron: the other proposal is that :is() is different from :has() in now two ways<br>
&lt;TabAtkins> TabAtkins: you're confusing it with :where. :has() is completely different<br>
&lt;TabAtkins> dbaron: i'm not a fan of these names<br>
&lt;TabAtkins> dbaron: no strong suggestions for what to do about it<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> TabAtkins: Regardless of our opinions on :where(), that's not the current issue<br>
&lt;TabAtkins> dbaron: I do think it compounds the problem tho<br>
&lt;TabAtkins> fantasai: What if we just restricted forgivingness to :is() and :where() and nowhere else. If you really want it you can get it, and these two are basically just syntactic sugar for expanding things out anyway.<br>
&lt;fantasai> TabAtkins: if breakage is enough to worry about, and I think it might be<br>
&lt;florian> q?<br>
&lt;fantasai> TabAtkins: then that's my preferred solution of all of them<br>
&lt;TabAtkins> florian: so if that's the path we go, if you want forgiving-ness, you just do :has(:is()) ?<br>
&lt;TabAtkins> TabAtkins: yeah<br>
&lt;fantasai> TabAtkins: given that some ppl who know about badness of breakage aren't here<br>
&lt;fantasai> TabAtkins: I suggest we defer this, and say that if breakage is bad enough, we go with forgivingness only in :is() and :where()?<br>
&lt;fantasai> TabAtkins: We basically narrow to 2 options here<br>
&lt;fantasai> astearns: or switch it to unforgiving regardless<br>
&lt;fantasai> heycam|away: how do we decide if it's bad enough?<br>
&lt;fantasai> TabAtkins: been awhile since I looked<br>
&lt;fantasai> iank_: I think it was bad enough that we need to make a change<br>
&lt;TabAtkins> dbaron: I think the breakage came from jquery's test suite, not real sites<br>
&lt;TabAtkins> dbaron: but not sure<br>
&lt;astearns> https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1235441907<br>
&lt;TabAtkins> fantasai: that said, we still have you concerns<br>
&lt;TabAtkins> astearns: this comment says even if we make it unforgiving, :is() is still forgiving so it's a problem<br>
&lt;fantasai> TabAtkins: I made that comment, and response was that because :is() isn't part of jquery, much much less likely to trigger a problem<br>
&lt;fantasai> TabAtkins: it relies on code writing new standards-based selectors using :is() in old versions of jquery, which while it can happen is much less likely than new pages<br>
&lt;TabAtkins> TabAtkins: than old pages using jQuery's :has() and breaking due to the new standard :has()<br>
&lt;TabAtkins> astearns: So collect more info, provsionally conclude that making :has() unforgiving may be the path to fix if breakage is bad?<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-1249958942 using your GitHub account


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

Received on Saturday, 17 September 2022 00:31:35 UTC