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)
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) 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
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/4af7fbf5-1bf5-4c51-b82c-6d01e2c61634n%40chromium.org?utm_medium=email&utm_source=footer>.
