On Fri, Sep 2, 2022 at 11:40 AM Rune Lillesveen <[email protected]> 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 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> 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 <[email protected]> wrote: >>>>> >>>>>> >>>>>> On 5/18/22 17:33, Antti Koivisto wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Tuesday, May 17, 2022 at 9:19:03 AM UTC+3 [email protected] 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 [email protected]. >>>>>> 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 [email protected]. >>>> 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 [email protected]. >>>> 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 [email protected]. >>> 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 [email protected]. >> 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 -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACuPfeREJ%3D197T7TP0hd%2BZOD9hqyWF_QsqqCnzciB-0DpnwSxg%40mail.gmail.com.
