Thank you for checking the issue and sorry for not being able to prevent it in advance.
I missed the risk of conflicting with JQuery's :has() implementation. I apologize for not checking enough. I made a CL to avoid current JQuery conflict by following the WebKit behavior: - https://chromium-review.googlesource.com/c/chromium/src/+/3868781 After the CL merged, these web-platform-tests results will be same with WebKit: - https://wpt.fyi/results/css/selectors/has-error-recovery.html - https://wpt.fyi/results/css/selectors/parsing/parse-has-disallow-nesting-has-inside-has.html - https://wpt.fyi/results/css/selectors/parsing/parse-has.html If it looks OK, I'll try to merge it asap. 2022년 9월 2일 금요일 오후 9시 52분 35초 UTC+9에 Rune Lillesveen님이 작성: > On Fri, Sep 2, 2022 at 2:39 PM Yoav Weiss <yoav...@chromium.org> wrote: > >> >> >> On Fri, Sep 2, 2022 at 2:19 PM Rune Lillesveen <fut...@chromium.org> >> wrote: >> >>> On Fri, Sep 2, 2022 at 1:37 PM Yoav Weiss <yoav...@chromium.org> wrote: >>> >>>> 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. >>>> >>> >>> That is correct. >>> >>> It could be that the best way short term is to change the implementation >>> to not allow forgiving selectors lists. Authors should be able to get the >>> same forgiving effect for :has() sprinkling :is() at appropriate places. >>> >> >> Given that a code change is required anyways, that sounds reasonable.. >> > > New update about the WebKit implementation: > > https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1235450787 > > They _do_ support a forgiving selector list, with a small twist that if > all selectors are invalid and end up with an empty :has(), the selector is > dropped. > > >> >>> >>> Slightly longer term, the spec issue for possibly changing it is here: >>> https://github.com/w3c/csswg-drafts/issues/7676 >>> >>> On Fri, Sep 2, 2022 at 1:11 PM Rune Lillesveen <fut...@chromium.org> >>>> wrote: >>>> >>>>> On Fri, Sep 2, 2022 at 1:09 PM Rune Lillesveen <fut...@chromium.org> >>>>> wrote: >>>>> >>>>>> On Fri, Sep 2, 2022 at 11:40 AM Rune Lillesveen <fut...@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 <chri...@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 <brat...@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 <bl...@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+...@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+...@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+...@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+...@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 >>>>> >>>>> >>> >>> -- >>> 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/3d295acd-7afe-44c6-ba67-00612808699bn%40chromium.org.
