On Fri, Sep 2, 2022 at 2:19 PM Rune Lillesveen <[email protected]> wrote:
> On Fri, Sep 2, 2022 at 1:37 PM Yoav Weiss <[email protected]> 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.. > > 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 <[email protected]> >> wrote: >> >>> On Fri, Sep 2, 2022 at 1:09 PM Rune Lillesveen <[email protected]> >>> wrote: >>> >>>> 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 >>>> >>> >>> 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 <[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 >>>> >>>> >>> >>> -- >>> 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/CAL5BFfW6mk-%3DWOL%2B-dyOS_dNmurb5qpftKzX3MUGbGdVd9vJDA%40mail.gmail.com.
