We resolved to be bug compatible with Safari as the jquery breakage was too risky to keep. This change has landed on the branches for 105, 106, and on main (107)
The discussion around forgiving selectors will continue in https://github.com/w3c/csswg-drafts/issues/7676 On Fri, Sep 2, 2022 at 4:41 PM Byungwoo Lee <[email protected]> wrote: > Thank you for checking the issue and sorry for not being able to prevent > it in advance. > > I missed the risk of conflicting with JQuery's :has() implementation. I > apologize for not checking enough. > > I made a CL to avoid current JQuery conflict by following the WebKit > behavior: > - https://chromium-review.googlesource.com/c/chromium/src/+/3868781 > > After the CL merged, these web-platform-tests results will be same with > WebKit: > - https://wpt.fyi/results/css/selectors/has-error-recovery.html > - > https://wpt.fyi/results/css/selectors/parsing/parse-has-disallow-nesting-has-inside-has.html > - https://wpt.fyi/results/css/selectors/parsing/parse-has.html > > If it looks OK, I'll try to merge it asap. > > 2022년 9월 2일 금요일 오후 9시 52분 35초 UTC+9에 Rune Lillesveen님이 작성: > >> On Fri, Sep 2, 2022 at 2:39 PM Yoav Weiss <[email protected]> wrote: >> >>> >>> >>> 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.. >>> >> >> 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 <[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 >>>> >>>> >> >> -- >> 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/CACuPfeRWOiMNbE4Kzm_XZf6k%2BGBpF6iVK%2BOGrCwo1CqqKksBoQ%40mail.gmail.com.
