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! 2022년 5월 20일 금요일 오후 2시 49분 3초 UTC+9에 bl...@igalia.com님이 작성: > 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/a274e0de-df75-476c-8ccc-1773d5148fe3n%40chromium.org.
