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 > > > To be clear, in general I'd favor shipping with the limitations in place > for now, and if/when there are use cases and so to unrestrict them do so. > But that said, for that we need proper detection for those limitations. I > filed this on the topic: > > * https://github.com/w3c/csswg-drafts/issues/7280 > > Your suggestion to `@supports` seems to help detect the limitations, so I > left a comment. Thank you for filing the issue! > > > > -- Emilio > > > Regards, > 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/b95182b2-1127-41aa-bac1-0079eed553f2n%40chromium.org.
