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.
