Thanks for the update!

LGTM1 to ship, once we're aligned with the spec and WG decisions.

On Thu, Jun 2, 2022 at 9:25 AM Byungwoo Lee <[email protected]> wrote:

> 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)
>>>>       - ':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:
>>>       - we should consider ':is()', ':where()', ':not()' as a whole in
>>>       terms of complexity,
>>>       - those cases (especially ':not()') enables useful cases
>>>       - invalidation performance will not be great but also it will not
>>>       be different compared to some other worst cases
>>>       - 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
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b7f0fddb-cf49-5d4d-55ea-592f7a7578d5%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/CAL5BFfXap%3DKEvkQgr2ZZRtXPNFJvm1xJfRG%2Bdje7aH56obdU0g%40mail.gmail.com.

Reply via email to