On Fri, Sep 2, 2022 at 2:39 PM Yoav Weiss <yoavwe...@chromium.org> wrote:
> > > On Fri, Sep 2, 2022 at 2:19 PM Rune Lillesveen <futh...@chromium.org> > wrote: > >> 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. >> > > 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 <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 >> >> -- 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/CACuPfeSCbtbz0bbrJd-KKMhxeUwYVPE1QDv5U_%2B5kBJreQ4QBg%40mail.gmail.com.
