On Fri, Sep 2, 2022 at 1:37 PM Yoav Weiss <yoavwe...@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. 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 <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 >> >> -- 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/CACuPfeTiF-ZXadXLid4_t_yTNExASBo9v_n%2B5LX_rDzdFA9e-Q%40mail.gmail.com.
