There is an update!
1. All the :has() related issues have been resolved in CSSWG
<https://lists.w3.org/Archives/Public/www-style/2022Jun/0003.html>.
(Thanks to everyone who arranged and discussed!)
#6399 <https://github.com/w3c/csswg-drafts/issues/6399> Remove the
:scope dependency from the relative selectors definition ()
-> Remove special handling of :scope in relative selectors generally
#6952 <https://github.com/w3c/csswg-drafts/issues/6952> Consider
disallowing logical combination pseudo-classes inside :has()
-> Disallow nesting :has() inside :has()
#7280 <https://github.com/w3c/csswg-drafts/issues/7280> Detecting
:has() restrictions
-> @supports uses non-forgiving parsing for all selectors
#6845 <https://github.com/w3c/csswg-drafts/issues/6845> Consider
disallowing :has() outside the rightmost compound
-> Close no change
#7211 <https://github.com/w3c/csswg-drafts/issues/7211> Consider
disallowing :scope inside :has()
-> Closed as a duplicate of #6399 (continues to be allowed inside
:has())
#7212 <https://github.com/w3c/csswg-drafts/issues/7212> Consider
disallowing :host, :host(), :host-context() inside :has()
-> No change; :host etc. continues to be allowed inside :has()
2. Chrome implementation has already followed the above resolutions.
Currently, :has() works as expected based on the spec and the above
resolved results.
The only bug that remains is about some invalidation cases for
logical combinations inside :has() (bug 1331207
<https://bugs.chromium.org/p/chromium/issues/detail?id=1331207>),
and I prepared CLs to fix the bug.
Please let us know if there is any other considerations.
Thank you!
On 5/20/22 14:49, Byungwoo Lee wrote:
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>.
--
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/b7f0fddb-cf49-5d4d-55ea-592f7a7578d5%40igalia.com.
