Thanks for the update! Given that this is something that web developers have been using (as a polyfill, but still) for a loooong while, I'm somewhat skeptical that we can get away with the spec as currently written. As we can't have use-counters for things passed as jquery selectors, I wonder if an HTTPArchive and a GitHub search can reveal how widespread this is.
But I suspect this is a "revert first and ask questions later" kind of situation. Unfortunately, it seems like this would require a code update, as the flag is not propagated to a Chromium feature flag <https://source.chromium.org/search?q=CSSPseudoHas%20-f:out&sq=&ss=chromium%2Fchromium%2Fsrc> AFAICT. On Fri, Sep 2, 2022 at 1:11 PM Rune Lillesveen <futh...@chromium.org> wrote: > On Fri, Sep 2, 2022 at 1:09 PM Rune Lillesveen <futh...@chromium.org> > wrote: > >> On Fri, Sep 2, 2022 at 11:40 AM Rune Lillesveen <futh...@chromium.org> >> wrote: >> >>> Hi all, >>> >>> We have an incoming issue for jQuery that seems pretty serious for them: >>> >> >> An update on the impact for jQuery: >> >> https://github.com/jquery/jquery/issues/5098#issuecomment-1235351545 >> > > There was an issue filed for the CSSWG > https://github.com/w3c/csswg-drafts/issues/7676 > > https://crbug.com/1358953 >>> >>> The problem is that jQuery uses the native implementation of :has() when >>> present, but the feature detection detects support for other custom jQuery >>> selectors inside :has() because of :has() accepting forgiving selectors. >>> >>> It should be possible to fix this for jQuery, but the problem is for >>> existing content which relies on this feature detection. >>> >>> The reason why this was not detected when Safari shipped :has(), is that >>> Safari does not accept <forgiving-relative-selector-list> like the spec >>> says. I have filed https://bugs.webkit.org/show_bug.cgi?id=244708 >>> against WebKit. >>> >>> On Thu, Jun 2, 2022 at 5:57 PM Chris Harrelson <chris...@chromium.org> >>> wrote: >>> >>>> LGTM3, once the implementation aligns with the WG decisions, there are >>>> tests, and the corresponding spec PRs have landed. >>>> >>>> Congratulations to all who worked on this feature! I think it's a great >>>> addition to the platform that developers will really like. >>>> >>>> On Thu, Jun 2, 2022 at 1:25 AM Daniel Bratell <bratel...@gmail.com> >>>> wrote: >>>> >>>>> LGTM2 >>>>> >>>>> /Daniel >>>>> >>>>> >>>>> On 2022-06-02 10:05, Yoav Weiss wrote: >>>>> >>>>> Thanks for the update! >>>>> >>>>> LGTM1 to ship, once we're aligned with the spec and WG decisions. >>>>> >>>>> On Thu, Jun 2, 2022 at 9:25 AM Byungwoo Lee <b...@igalia.com> wrote: >>>>> >>>>>> There is an update! >>>>>> >>>>>> 1. All the :has() related issues have been resolved in CSSWG >>>>>> <https://lists.w3.org/Archives/Public/www-style/2022Jun/0003.html> >>>>>> . >>>>>> (Thanks to everyone who arranged and discussed!) >>>>>> >>>>>> #6399 <https://github.com/w3c/csswg-drafts/issues/6399> Remove >>>>>> the :scope dependency from the relative selectors definition () >>>>>> -> Remove special handling of :scope in relative selectors >>>>>> generally >>>>>> #6952 <https://github.com/w3c/csswg-drafts/issues/6952> Consider >>>>>> disallowing logical combination pseudo-classes inside :has() >>>>>> -> Disallow nesting :has() inside :has() >>>>>> #7280 <https://github.com/w3c/csswg-drafts/issues/7280> Detecting >>>>>> :has() restrictions >>>>>> -> @supports uses non-forgiving parsing for all selectors >>>>>> #6845 <https://github.com/w3c/csswg-drafts/issues/6845> Consider >>>>>> disallowing :has() outside the rightmost compound >>>>>> -> Close no change >>>>>> #7211 <https://github.com/w3c/csswg-drafts/issues/7211> Consider >>>>>> disallowing :scope inside :has() >>>>>> -> Closed as a duplicate of #6399 (continues to be allowed >>>>>> inside :has()) >>>>>> #7212 <https://github.com/w3c/csswg-drafts/issues/7212> Consider >>>>>> disallowing :host, :host(), :host-context() inside :has() >>>>>> -> No change; :host etc. continues to be allowed inside :has() >>>>>> >>>>>> 2. Chrome implementation has already followed the above >>>>>> resolutions. >>>>>> Currently, :has() works as expected based on the spec and the >>>>>> above resolved results. >>>>>> The only bug that remains is about some invalidation cases for >>>>>> logical combinations inside :has() (bug 1331207 >>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1331207>), >>>>>> and I prepared CLs to fix the bug. >>>>>> >>>>>> >>>>>> Please let us know if there is any other considerations. >>>>>> >>>>>> Thank you! >>>>>> >>>>>> >>>>>> On 5/20/22 14:49, Byungwoo Lee wrote: >>>>>> >>>>>> Thank you for the reply! >>>>>> >>>>>> To address the issues, I've added a comment based on the latest >>>>>> communication in this thread. >>>>>> - >>>>>> https://github.com/w3c/csswg-drafts/issues/7211#issuecomment-1132432496 >>>>>> >>>>>> Hope this helps to solve the issues. >>>>>> >>>>>> 2022년 5월 19일 목요일 오전 7시 50분 52초 UTC+9에 Chris Harrelson님이 작성: >>>>>> >>>>>>> Hi Byungwoo, >>>>>>> >>>>>>> I think it would be better to resolve the referenced issues at the >>>>>>> CSSWG, including aspects Antti mentioned here, before shipping. >>>>>>> >>>>>>> >>>>>>> On Wed, May 18, 2022 at 6:05 AM Byungwoo Lee <bl...@igalia.com> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> On 5/18/22 17:33, Antti Koivisto wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tuesday, May 17, 2022 at 9:19:03 AM UTC+3 bl...@igalia.com >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> On 5/17/22 03:17, Emilio Cobos Álvarez wrote: >>>>>>>>> >>>>>>>>> On 5/16/22 11:05, Byungwoo Lee wrote: >>>>>>>>> >>>>>>>>> Anticipated spec changes >>>>>>>>> >>>>>>>>> There are 4 open issues posted on the csswg draft. >>>>>>>>> >>>>>>>>> * Remove scope dependency from relative selectors definition: >>>>>>>>> https://github.com/w3c/csswg-drafts/issues/6399 >>>>>>>>> * Disallowing logical combination pseudo classes inside >>>>>>>>> ':has()': >>>>>>>>> https://github.com/w3c/csswg-drafts/issues/6952 >>>>>>>>> * Disallowing ':scope' inside ':has()': >>>>>>>>> https://github.com/w3c/csswg-drafts/issues/7211 >>>>>>>>> * Disallowing ':host', ':host()', ':host-context()' inside >>>>>>>>> ':has()': >>>>>>>>> https://github.com/w3c/csswg-drafts/issues/7212 >>>>>>>>> >>>>>>>>> >>>>>>>>> It'd be great to get resolution on these issues before shipping, >>>>>>>>> IMO. >>>>>>>>> >>>>>>>>> In general, given how the usefulness of this feature relies on >>>>>>>>> browser engines having predictable performance (the feature is >>>>>>>>> useless if >>>>>>>>> WebKit or Firefox get cases fast that Chrome gets slow or >>>>>>>>> vice-versa), it'd >>>>>>>>> be great to document in the spec some of these limitations and the >>>>>>>>> reasoning for them. >>>>>>>>> >>>>>>>>> All the above 4 issues are essentially related to the case of >>>>>>>>> ':is()' inside ':has()'. >>>>>>>>> >>>>>>>>> The dependency between the 4 issues can be summarized as follows: >>>>>>>>> >>>>>>>>> - To avoid increasing invalidation complexity, disallow >>>>>>>>> ':is()' or ':where()' inside ':has()' (#6952) >>>>>>>>> - ':scope' inside ':has()' has the same (or worse) problem >>>>>>>>> as ':is()' inside ':has()', so disallow ':scope' inside >>>>>>>>> ':has()' (#7211) >>>>>>>>> - After ':scope' is disallowed inside ':has()', we can >>>>>>>>> keep the current definition of absolutizing with ':scope' >>>>>>>>> because ':scope' >>>>>>>>> will not be used explicitly inside the ':has()' (#6399) >>>>>>>>> - ':host', ':host()', ':host-context()' is meaningless >>>>>>>>> unless it is used with ':scope' inside ':has()' (#7212) >>>>>>>>> >>>>>>>>> >>>>>>>>> The ':is()' inside ':has()' case is the start of the 4 issues, and >>>>>>>>> most engines seems to agree to disallow the ':is()' inside ':has()' >>>>>>>>> case >>>>>>>>> now. >>>>>>>>> >>>>>>>>> If so, I think it would be OK to ship to Chrome with explicit >>>>>>>>> limitations for the above cases even if those issues are not yet >>>>>>>>> addressed >>>>>>>>> in the spec. How do you think about this? >>>>>>>>> >>>>>>>> WebKit does not disallow :is() inside :has() and I don't see a >>>>>>>> particular reason to. While not very useful it does not increase >>>>>>>> complexity >>>>>>>> over :not() inside :has() (which is supported and people have found >>>>>>>> useful). The only current limitation with logical combinator >>>>>>>> pseudo-classes >>>>>>>> is disallowing :has() nested inside :has() (which increases complexity >>>>>>>> a >>>>>>>> lot without enabling anything useful). >>>>>>>> >>>>>>>> antti >>>>>>>> >>>>>>>> I think I misunderstood that the option of disallowing ':is()' >>>>>>>> inside ':has()' is still alive. Also I overlooked that ':not()' inside >>>>>>>> ':has()' has the same problem as ':is()' inside ':has()'. >>>>>>>> >>>>>>>> I communicated with Antti about the above limitations, and we both >>>>>>>> agreed these: >>>>>>>> >>>>>>>> - Positive on disallowing explicit ':scope' inside ':has()' >>>>>>>> since ':has()' has an implicit scope. >>>>>>>> - Positive on disallowing ':has()' inside ':has()' since it can >>>>>>>> increase complexity a lot. >>>>>>>> - Should allow ':is()'/':where()' inside ':has() since: >>>>>>>> - we should consider ':is()', ':where()', ':not()' as a >>>>>>>> whole in terms of complexity, >>>>>>>> - those cases (especially ':not()') enables useful cases >>>>>>>> - invalidation performance will not be great but also it >>>>>>>> will not be different compared to some other worst cases >>>>>>>> - both WebKit and Chrome haven't considered some >>>>>>>> invalidation cases, (https://codepen.io/byung-woo/pen/vYdxPMa) >>>>>>>> but fixing the bug will not be very complex or difficult. >>>>>>>> >>>>>>>> Based on this consensus, I'm going to allow ':is()' and ':where()' >>>>>>>> inside ':has()' before shipping. >>>>>>>> >>>>>>>> The bug pointed at above will *not* be fixed before shipping. >>>>>>>> >>>>>>>> Since it is positive to disallow explicit ':scope' inside ':has()', >>>>>>>> I think disallowing ':host()' inside ':has()' is still reasonable. >>>>>>>> >>>>>>>> How about this? >>>>>>>> >>>>>>>> >>>>>>>> Byungwoo. >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "blink-dev" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to blink-dev+...@chromium.org. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b8aba55a-2ea6-4b75-bf13-f04e27661938%40igalia.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b8aba55a-2ea6-4b75-bf13-f04e27661938%40igalia.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "blink-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to blink-dev+unsubscr...@chromium.org. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4af7fbf5-1bf5-4c51-b82c-6d01e2c61634n%40chromium.org >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4af7fbf5-1bf5-4c51-b82c-6d01e2c61634n%40chromium.org?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "blink-dev" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to blink-dev+unsubscr...@chromium.org. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b7f0fddb-cf49-5d4d-55ea-592f7a7578d5%40igalia.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b7f0fddb-cf49-5d4d-55ea-592f7a7578d5%40igalia.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to blink-dev+unsubscr...@chromium.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXap%3DKEvkQgr2ZZRtXPNFJvm1xJfRG%2Bdje7aH56obdU0g%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXap%3DKEvkQgr2ZZRtXPNFJvm1xJfRG%2Bdje7aH56obdU0g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to blink-dev+unsubscr...@chromium.org. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-YkwgDK0F_zMQN4R3sZECCd3vT5-y2-mvDCvM%2BGX_HhQ%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-YkwgDK0F_zMQN4R3sZECCd3vT5-y2-mvDCvM%2BGX_HhQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >>> >>> -- >>> Rune Lillesveen >>> >>> >> >> -- >> Rune Lillesveen >> >> > > -- > Rune Lillesveen > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUNa7j4fE8An3A4Hqf69SXpKaCiMQ77wTcoJ8-kP3qsgw%40mail.gmail.com.
