That's great to hear, thanks for the update. On Friday, September 9, 2022 at 9:51:19 AM UTC-4 Rune Lillesveen wrote:
> We resolved to be bug compatible with Safari as the jquery breakage was > too risky to keep. This change has landed on the branches for 105, 106, and > on main (107) > > The discussion around forgiving selectors will continue in > https://github.com/w3c/csswg-drafts/issues/7676 > > On Fri, Sep 2, 2022 at 4:41 PM Byungwoo Lee <b...@igalia.com> wrote: > >> 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 >>> >>> > > -- > 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/46c0e04f-9ba8-4176-a8b5-082aa174417cn%40chromium.org.
