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)
o ':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:
o we should consider ':is()', ':where()', ':not()' as a whole in
terms of complexity,
o those cases (especially ':not()') enables useful cases
o invalidation performance will not be great but also it will not
be different compared to some other worst cases
o both WebKit and Chrome haven't considered some invalidation
cases, (https://codepen.io/byung-woo/pen/vYdxPMa
<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+unsubscr...@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.
