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?
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/a8a0dcff-6b7e-29bb-5d86-d57383f5d6d2%40igalia.com.
