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/CAOMQ%2Bw9GYoMSO2gaxgBHZgRSMAaJ%3DA5Exp3%2Bd_A_H9hChMd1Ng%40mail.gmail.com.
