Hi all, We have an incoming issue for jQuery that seems pretty serious for them:
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 -- 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/CACuPfeQrbQ1ZrgNAm2T5SYM_gUBebQQAYMSv_OQ%3Dk-MQwOpgcA%40mail.gmail.com.
