Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Byungwoo Lee]

Something wrong with the citation style of the previous mail. I'll send the 
reply again.

>>> OK, so for where we're risking seeing more fallbacks than before, but 
according to your manual inspection, that seems fine? 
>> Yes, I think so.
>> Based on the usage metrics, only about 0.5 % of page loads could be 
affected by this feature. Considering the manual investigation on the top 
pages (only 1 of of 10 is for `:where()`, and the rest are for `:has()`. no 
urls for `:is()`), the ratio of the `:where()` is likely to be much less 
than 0.5 %.
> In the manual inspection, how many function calls had a mix of valid and 
invalid selectors? (that would be impacted by this change)
There is no mix of valid and invalid in the manual inspection for the top 
URLs. :has() and :where() are used only with empty argument or valid 
argument.


>> Will it be better to add a feature for this change and add some metrics 
(something like, how many page loads use :has() with both valid and invalid 
selector) before releasing it to stable?
> Adding a feature (including a base_feature) to the `:has` change would be 
good. Would you be able to merge that back to 110?
> I think we should tie the `:has` change to this intent. The risk profile 
seems similar.
I made a CL that adds 'CSSPseudoHasNonForgivingParsing' feature (
https://chromestatus.com/feature/6177049203441664) for the change:
- https://chromium-review.googlesource.com/c/chromium/src/+/4151453

The CL also adds two metrics so that we can get usecounter of the cases 
that the change affects:
- CSSPseudoHasContainsMixOfValidAndInvalid : ':has(a, :foo)'
- CSSPseudoIsWhereContainsMixOfValidAndInvalid : ':is(a, :foo)', ':where(a, 
:foo)'

 I'll try to merge the CL to 110 branch after it landed.


2023년 1월 11일 수요일 오후 2시 33분 10초 UTC+9에 Byungwoo Lee님이 작성:

>
>
> 2023년 1월 9일 월요일 오후 7시 36분 34초 UTC+9에 yoav...@chromium.org님이 작성:
> On Mon, Jan 9, 2023 at 11:12 AM Byungwoo Lee  wrote:
> Thanks! I replied again. :)
>
> 2023년 1월 6일 금요일 오후 7시 50분 43초 UTC+9에 yoav...@chromium.org님이 작성:
> On Thu, Jan 5, 2023 at 4:59 PM Byungwoo Lee  wrote:
> Added missing links.
>
> 2023년 1월 6일 금요일 오전 12시 52분 25초 UTC+9에 Byungwoo Lee님이 작성:
>
> Thanks for asking!
>
>
> > Is this change covered by a base feature flag?
>
> This is behind 'CSSAtSupportsAlwaysNonForgivingParsing' flag, and the flag 
> doesn't have 'base_feature' field yet. I'll add the field to the feature 
> before enable it.
>
>
> > Can you clarify if the ':has()' behavior will change here or not? This 
> last sentence seems to contradict the original message of the intent.
>
> > Can you confirm that both these cases won't break?
>
> There's a bit of twisted history here, so it would be better to answer 
> these two questions at once. (Sorry for the long answer!)
>
>
> 1. What can this feature change?
>
> After this feature enabled, `@supports selector()` can return different 
> result when it checks forgiving-parsing pseudo class.
>
> For example, `@supports selector(:where(:foo, a))` returns true now 
> (forgiving parsing drops invalid `:foo` inside `:where()`, so the 
> `:where(:foo, a)` becomes a valid selector `:where(a)` after forgiving 
> parsing), but it will return false after this feature enabled 
> (`:where(:foo, a)` will be invalid inside `@supports selector()`).
>
> OK, so for where we're risking seeing more fallbacks than before, but 
> according to your manual inspection, that seems fine? 
>
> Yes, I think so.
> Based on the usage metrics, only about 0.5 % of page loads could be 
> affected by this feature. Considering the manual investigation on the top 
> pages (only 1 of of 10 is for `:where()`, and the rest are for `:has()`. no 
> urls for `:is()`), the ratio of the `:where()` is likely to be much less 
> than 0.5 %.
>
> In the manual inspection, how many function calls had a mix of valid and 
> invalid selectors? (that would be impacted by this change)
> There is no mix of valid and invalid in the manual inspection for the top 
> URLs. :has() and :where() are used only with empty argument or valid 
> argument.
>  
>  
>
> But I cannot say that this feature will not affect at all, or that will be 
> the exact numbers that this feature actually affects after 110(unforgiving 
> `:has()`) released.
>
> I think we can get the number at about Apr (the next month after the 110 
> released).
>
> Will it be better to wait more so that we can see the number only for 
> `:where()` and `:is()`? 
>
>
> 2. How is this feature related to `:has()`?
>
> This `@supports` behavior change was applied to the spec [1] while 
> resolving an issue of `:has()` [2]. At that time, `:has()` was a 
> forgiving-parsing pseudo class. So this feature was able to change the 
> re

Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Byungwoo Lee]

2023년 1월 9일 월요일 오후 7시 36분 34초 UTC+9에 yoav...@chromium.org님이 작성:
On Mon, Jan 9, 2023 at 11:12 AM Byungwoo Lee  wrote:
Thanks! I replied again. :)

2023년 1월 6일 금요일 오후 7시 50분 43초 UTC+9에 yoav...@chromium.org님이 작성:
On Thu, Jan 5, 2023 at 4:59 PM Byungwoo Lee  wrote:
Added missing links.

2023년 1월 6일 금요일 오전 12시 52분 25초 UTC+9에 Byungwoo Lee님이 작성:

Thanks for asking!


> Is this change covered by a base feature flag?

This is behind 'CSSAtSupportsAlwaysNonForgivingParsing' flag, and the flag 
doesn't have 'base_feature' field yet. I'll add the field to the feature 
before enable it.


> Can you clarify if the ':has()' behavior will change here or not? This 
last sentence seems to contradict the original message of the intent.

> Can you confirm that both these cases won't break?

There's a bit of twisted history here, so it would be better to answer 
these two questions at once. (Sorry for the long answer!)


1. What can this feature change?

After this feature enabled, `@supports selector()` can return different 
result when it checks forgiving-parsing pseudo class.

For example, `@supports selector(:where(:foo, a))` returns true now 
(forgiving parsing drops invalid `:foo` inside `:where()`, so the 
`:where(:foo, a)` becomes a valid selector `:where(a)` after forgiving 
parsing), but it will return false after this feature enabled 
(`:where(:foo, a)` will be invalid inside `@supports selector()`).

OK, so for where we're risking seeing more fallbacks than before, but 
according to your manual inspection, that seems fine? 

Yes, I think so.
Based on the usage metrics, only about 0.5 % of page loads could be 
affected by this feature. Considering the manual investigation on the top 
pages (only 1 of of 10 is for `:where()`, and the rest are for `:has()`. no 
urls for `:is()`), the ratio of the `:where()` is likely to be much less 
than 0.5 %.

In the manual inspection, how many function calls had a mix of valid and 
invalid selectors? (that would be impacted by this change)
There is no mix of valid and invalid in the manual inspection for the top 
URLs. :has() and :where() are used only with empty argument or valid 
argument.
 
 

But I cannot say that this feature will not affect at all, or that will be 
the exact numbers that this feature actually affects after 110(unforgiving 
`:has()`) released.

I think we can get the number at about Apr (the next month after the 110 
released).

Will it be better to wait more so that we can see the number only for 
`:where()` and `:is()`? 


2. How is this feature related to `:has()`?

This `@supports` behavior change was applied to the spec [1] while 
resolving an issue of `:has()` [2]. At that time, `:has()` was a 
forgiving-parsing pseudo class. So this feature was able to change the 
result of `@supports selector(:has(:foo, a))` at first.

But it is not true now since `:has()` is changed to unforgiving while 
resolving the jQuery `:has()` conflict issue [3].

Hmm, so the behavior change to `:has` landed 
<https://chromium-review.googlesource.com/c/chromium/src/+/4090967> in M110 
without a feature flag nor an intent. How confident are we that this is 
safe?
^^ +Rune Lillesveen 

I think it would not make a critical issue since,
1. the change only affects `:has()` validity if the `:has()` contains both 
valid and invalid arguments (e.g. `:has(:foo, a) { ... }`), and it will not 
be used often in the wild.
I got a comment saying something similar while landing the jQuery 
workaround  - 
https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1235724730
2. the change fixes the inconsistency in the existing :has() validity logic.
- Currently, `:has()`, `:has(:foo)` and `:has(:foo, :bar)` are invalid, 
but `:has(:foo, a)` is valid.
- After the change merged, all the above are invalid selector.
3. Basically, the conflict from the change(making `:has()` unforgiving) can 
be easily fixed by changing the selector. (e.g. change `:has(:foo, a) 
{...}` to `:has(:where(:foo, a)) {...}` or `where(:has(:foo), :has(a)) 
{...}`),

Will it be better to add a feature for this change and add some metrics 
(something like, how many page loads use :has() with both valid and invalid 
selector) before releasing it to stable?

Adding a feature (including a base_feature) to the `:has` change would be 
good. Would you be able to merge that back to 110?

I think we should tie the `:has` change to this intent. The risk profile 
seems similar.

I made a CL that adds 'CSSPseudoHasNonForgivingParsing' feature 
(https://chromestatus.com/feature/6177049203441664) for the change:
- https://chromium-review.googlesource.com/c/chromium/src/+/4151453

The CL also adds two metrics so that we can get usecounter of the cases 
that the change affects:
- CSSPseudoHasContainsMixOfValidAndInvalid : ':has(a, :foo)'
- CSSPseudoIsWhereContainsMixOfValidAndInvalid : ':is(a, :foo)', ':where(a, 
:foo)'

 I'll try to merge the CL to 110 branch after it landed.
 
 
 

Now this feature

Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Byungwoo Lee]

Thanks! I replied again. :)

2023년 1월 6일 금요일 오후 7시 50분 43초 UTC+9에 yoav...@chromium.org님이 작성:

> On Thu, Jan 5, 2023 at 4:59 PM Byungwoo Lee  wrote:
>
>> Added missing links.
>>
>> 2023년 1월 6일 금요일 오전 12시 52분 25초 UTC+9에 Byungwoo Lee님이 작성:
>>
>>> Thanks for asking!
>>>
>>>
>>> > Is this change covered by a base feature flag?
>>>
>>> This is behind 'CSSAtSupportsAlwaysNonForgivingParsing' flag, and the 
>>> flag doesn't have 'base_feature' field yet. I'll add the field to the 
>>> feature before enable it.
>>>
>>>
>>> > Can you clarify if the ':has()' behavior will change here or not? This 
>>> last sentence seems to contradict the original message of the intent.
>>>
>>> > Can you confirm that both these cases won't break?
>>>
>>> There's a bit of twisted history here, so it would be better to answer 
>>> these two questions at once. (Sorry for the long answer!)
>>>
>>>
>>> 1. What can this feature change?
>>>
>>> After this feature enabled, `@supports selector()` can return different 
>>> result when it checks forgiving-parsing pseudo class.
>>>
>>> For example, `@supports selector(:where(:foo, a))` returns true now 
>>> (forgiving parsing drops invalid `:foo` inside `:where()`, so the 
>>> `:where(:foo, a)` becomes a valid selector `:where(a)` after forgiving 
>>> parsing), but it will return false after this feature enabled 
>>> (`:where(:foo, a)` will be invalid inside `@supports selector()`).
>>>
>>
> OK, so for where we're risking seeing more fallbacks than before, but 
> according to your manual inspection, that seems fine? 
>

Yes, I think so.
Based on the usage metrics, only about 0.5 % of page loads could be 
affected by this feature. Considering the manual investigation on the top 
pages (only 1 of of 10 is for `:where()`, and the rest are for `:has()`. no 
urls for `:is()`), the ratio of the `:where()` is likely to be much less 
than 0.5 %.

But I cannot say that this feature will not affect at all, or that will be 
the exact numbers that this feature actually affects after 110(unforgiving 
`:has()`) released.

I think we can get the number at about Apr (the next month after the 110 
released).

Will it be better to wait more so that we can see the number only for 
`:where()` and `:is()`?


>>> 2. How is this feature related to `:has()`?
>>>
>>> This `@supports` behavior change was applied to the spec [1] while 
>>> resolving an issue of `:has()` [2]. At that time, `:has()` was a 
>>> forgiving-parsing pseudo class. So this feature was able to change the 
>>> result of `@supports selector(:has(:foo, a))` at first.
>>>
>>> But it is not true now since `:has()` is changed to unforgiving while 
>>> resolving the jQuery `:has()` conflict issue [3].
>>>
>>
> Hmm, so the behavior change to `:has` landed 
> <https://chromium-review.googlesource.com/c/chromium/src/+/4090967> in 
> M110 without a feature flag nor an intent. How confident are we that this 
> is safe?
> ^^ +Rune Lillesveen 
>

I think it would not make a critical issue since,
1. the change only affects `:has()` validity if the `:has()` contains both 
valid and invalid arguments (e.g. `:has(:foo, a) { ... }`), and it will not 
be used often in the wild.
I got a comment saying something similar while landing the jQuery 
workaround  - 
https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1235724730
2. the change fixes the inconsistency in the existing :has() validity logic.
- Currently, `:has()`, `:has(:foo)` and `:has(:foo, :bar)` are invalid, 
but `:has(:foo, a)` is valid.
- After the change merged, all the above are invalid selector.
3. Basically, the conflict from the change(making `:has()` unforgiving) can 
be easily fixed by changing the selector. (e.g. change `:has(:foo, a) 
{...}` to `:has(:where(:foo, a)) {...}` or `where(:has(:foo), :has(a)) 
{...}`),

Will it be better to add a feature for this change and add some metrics 
(something like, how many page loads use :has() with both valid and invalid 
selector) before releasing it to stable?
 

>
> Now this feature doesn't change the `@supports selector(:has(:foo, a))` 
>>> result. `@supports selector(:has(:foo, a))` returns always false regardless 
>>> of this feature since `:has(:foo, a)` is an invalid selector both inside 
>>> and outside of `@supports selector()`.
>>>
>>>
>>> 3. The history about empty `:has()`
>>>
>>> This is a tricky part.
>>> When the 105(the first `:has()` enabled version) is released to stable, 
>>> a wo

Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Byungwoo Lee]

ot sure but the `not` seems to be a workaround to make the block 
works.


> 2023년 1월 5일 목요일 오후 7시 8분 7초 UTC+9에 yoav...@chromium.org님이 작성:
>
>> Thanks!!
>>
>> A couple of questions below, plus another one: Is this change covered by 
>> a base feature 
>> <https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md#generate-a-instance-from-a-blink-feature>
>>  flag?
>>
>> On Wed, Jan 4, 2023 at 12:34 PM Byungwoo Lee  wrote:
>>
>>> I checked the top URLs in the ChromeStatus page. (TL;DR - this feature 
>>> looks not affect the existing behavior of the top URLs)
>>>
>>> I was able to categorize the URLs as below.
>>>
>>> 1. Checking `:has()` support
>>> - Most of the URLs use `@supports` to check `:has()` support.
>>> - `@support` behavior will not be changed for `:has()` (We can ignore 
>>> this case since `:has()` will be unforgiving after 110 released)
>>>
>>
>> Can you clarify if the ':has()' behavior will change here or not? This 
>> last sentence seems to contradict the original message of the intent.
>>  
>>
>>> - There are 2 sub cases:
>>>  - URLs using WordPress yootheme [1]
>>>  - URLs using jQuery `has()` [2]
>>>
>>
>> Can you confirm that both these cases won't break?
>>  
>>
>>>
>>> 2. Checking `:where()` support
>>> - Only one URL(https://learn.ooznest.co.uk/) uses `@supports` to check 
>>> `:where()` support.
>>> - `@supports` behavior will be changed for `:where()` after this feature 
>>> enabled, but it will not affect the behavior of the web page since the page 
>>> handles both support and not support case[3].
>>>
>>> The only problem that I can see from the top URLs is checking `:where()` 
>>> support, but it looks very rare case and it may be already handled like 
>>> learn.ooznest.co.uk.
>>> (I was able to see some incorrect usages while checking[4], but I think 
>>> it is another discussion of checking empty `:where()`, `:has()`)
>>>
>>> I think that this feature does not have critical impact on the existing 
>>> behavior. And as shared previously, Safari and Firefox already changed 
>>> their implementations.
>>>
>>> How about shipping this?
>>>
>>> 
>>>
>>> [1] 6 URLs (6/10):
>>>   - https://lavalmore.gr/
>>>   - https://www.kussenwereld.nl/
>>>   - https://thelocustgroveflowers.com/
>>>   - https://shop.bmgi.com.au/
>>>   - https://badaptor.com/
>>>   - https://suicidprev.se/
>>> 'theme1.css' of yootheme contains `@supports not selector(:has()) 
>>> {...}` statement.
>>> (e.g. 
>>> https://thelocustgroveflowers.com/wp-content/themes/locust-ff/css/theme.1.css?ver=1669913762
>>> )
>>> The `@supports not...` statement looks weird since the conditional 
>>> block contains rules using `:has()`.
>>>
>>> [2] 2 URLs (2/10):
>>>   - https://www.midroog.co.il/
>>>   - https://whadam.tistory.com/
>>>
>>> [3] A stylesheet file has `@supports selector(:where()) {...}` and 
>>> `@supports not selector(:where()) {...}` statement.
>>> (
>>> https://d3015z1jd0uox2.cloudfront.net/Assets/Guide/black/guide-all-j81VMtmAdGEcl2BaHR40jA.css
>>> )
>>> 
>>> [4] Passing empty `:has()` or `:where()` to `@supports selector()` to 
>>> check whether a browser supports the pseudo class.
>>> (e.g. `@supports not selector(:has())`, `@supports 
>>> selector(:where())`)
>>>
>>> 2023년 1월 3일 화요일 오후 6시 18분 31초 UTC+9에 Byungwoo Lee님이 작성:
>>>
>>>> Hello Yoav,
>>>>
>>>> Chrome status shows the number from stable now.
>>>>
>>>> I checked these metrics.
>>>> - https://chromestatus.com/metrics/feature/timeline/popularity/4361 
>>>> (CSSAtSupportsDropInvalidWhileForgivingParsing)
>>>> - https://chromestatus.com/metrics/feature/timeline/popularity/976 
>>>> (CSSAtRuleSupports)
>>>>
>>>> According to the above metrics, some pages will be affected by this 
>>>> feature but it seems to be a relatively small fraction:
>>>> - Only 0.50 % of page loads are dropping invalid selector while parsing 
>>>> forgiving selector inside '@supports selector()'.
>>>> - 41.10% of page loads are using '@supports', but on

Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Byungwoo Lee]

Thanks for asking!


> Is this change covered by a base feature flag?

This is behind 'CSSAtSupportsAlwaysNonForgivingParsing' flag, and the flag 
doesn't have 'base_feature' field yet. I'll add the field to the feature 
before enable it.


> Can you clarify if the ':has()' behavior will change here or not? This 
last sentence seems to contradict the original message of the intent.
> Can you confirm that both these cases won't break?

There's a bit of twisted history here, so it would be better to answer 
these two questions at once. (Sorry for the long answer!)


1. What can this feature change?

After this feature enabled, `@supports selector()` can return different 
result when it checks forgiving-parsing pseudo class.

For example, `@supports selector(:where(:foo, a))` returns true now 
(forgiving parsing drops invalid `:foo` inside `:where()`, so the 
`:where(:foo, a)` becomes a valid selector `:where(a)` after forgiving 
parsing), but it will return false after this feature enabled 
(`:where(:foo, a)` will be invalid inside `@supports selector()`).


2. How is this feature related to `:has()`?

This `@supports` behavior change was applied to the spec [1] while 
resolving an issue of `:has()` [2]. At that time, `:has()` was a 
forgiving-parsing pseudo class. So this feature was able to change the 
result of `@supports selector(:has(:foo, a))` at first.

But it is not true now since `:has()` is changed to unforgiving while 
resolving the jQuery `:has()` conflict issue [3].

Now this feature doesn't change the `@supports selector(:has(:foo, a))` 
result. `@supports selector(:has(:foo, a))` returns always false regardless 
of this feature since `:has(:foo, a)` is an invalid selector both inside 
and outside of `@supports selector()`.


3. The history about empty `:has()`

This is a tricky part.
When the 105(the first `:has()` enabled version) is released to stable, a 
workaround was merged [4] to avoid the jQuery conflict issue. 

At that time, `:has()` was a forgiving-parsing pseudo class, so 
`:has(:foo)` and `:has()` should be a valid selector.

But the workaround changed the behavior - make `:has()` invalid when all 
the arguments are dropped.
- `:has()` is invalid because it doesn't have any argument.
- `:has(:foo)` is invalid because it doesn't have any argument after the 
invalid argument `:foo` is dropped.
- `:has(:foo, a)` is valid because it has a valid argument `a` after the 
invalid argument `:foo` is dropped.

Last December, the jQuery conflict issue was resolved [3] and it was 
applied to 110 [5] - make `:has()` unforgiving.
- `:has()` is invalid because it doesn't have any argument.
- `:has(:foo)` is invalid because it has an invalid argument `:foo`.
- `:has(:foo, a)` is invalid because it has an invalid argument `:foo`.

Due to this, the result of `@supports selector(:has())` has been false 
since 105.


4. Why does this feature not affect URLs that use WordPress yootheme?

Because it checks with empty `:has()` - `@supports not selector(:has())`.

`@supports not selector(:has())` has been always true since 105, and it 
will still be true after this feature enabled because this feature doesn't 
affect unforgiving parsing.

The strange point is that the statement is useless(because it is always 
true) and semantically incorrect [6].


5. Why does this feature not affect URLs that use jQuery `:has()`?

Because the jQuery `has()` conflict issue was already resolved by making 
`:has()` unforgiving [3], [5], and this feature doesn't affect unforgiving 
parsing.


6. In short,

This feature will not affect `:has()` inside `@supports selector()`.

This feature can affects `:is()` or `where()` inside `@supports 
selector()`. (only when its argument is empty or invalid)


Hope that this has clarified the question.

2023년 1월 5일 목요일 오후 7시 8분 7초 UTC+9에 yoav...@chromium.org님이 작성:

> Thanks!!
>
> A couple of questions below, plus another one: Is this change covered by a 
> base 
> feature 
> <https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md#generate-a-instance-from-a-blink-feature>
>  flag?
>
> On Wed, Jan 4, 2023 at 12:34 PM Byungwoo Lee  wrote:
>
>> I checked the top URLs in the ChromeStatus page. (TL;DR - this feature 
>> looks not affect the existing behavior of the top URLs)
>>
>> I was able to categorize the URLs as below.
>>
>> 1. Checking `:has()` support
>> - Most of the URLs use `@supports` to check `:has()` support.
>> - `@support` behavior will not be changed for `:has()` (We can ignore 
>> this case since `:has()` will be unforgiving after 110 released)
>>
>
> Can you clarify if the ':has()' behavior will change here or not? This 
> last sentence seems to contradict the original message of the intent.
>  
>
>> - There are 2 sub cases:
>>  - URLs using WordPress yootheme [1]
>>

Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Byungwoo Lee]

- Percentage of page loads that use @supports rule
>>   (https://chromestatus.com/metrics/feature/timeline/popularity/976)
>>
>> The comparison doesn't prove anything, but I think we can at least guess 
>> how much the @supports change affects the existing behavior:
>> Assuming the current numbers in the above links are from stable, about 
>> 40% of the loaded pages use @supports rule, but only 0.002% of the loaded 
>> pages hit the case of dropping invalid selector while forgiving selector 
>> parsing inside @supports. By simply comparing the numbers, I think we can 
>> say that 1/2 of the @supports rule usages will be affected by the 
>> feature.
>>
>> 2022년 10월 10일 월요일 오후 11시 18분 41초 UTC+9에 Byungwoo Lee님이 작성:
>>
>>> To continue this thread after getting the stable Chrome's use counter, I 
>>> changed the estimated milestone of this feature from 109 to 111.
>>> I'll share the use counter after the version 108 released.
>>>
>>> Thank you!
>>>
>>> 2022년 9월 29일 목요일 오전 11시 52분 43초 UTC+9에 Byungwoo Lee님이 작성:
>>>
>>>>
>>>> On 9/27/22 10:07, Byungwoo Lee wrote:
>>>>
>>>>
>>>> On 9/24/22 00:40, Yoav Weiss wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Sep 23, 2022 at 5:25 PM Byungwoo Lee  wrote:
>>>>
>>>>> Hello Yoav and Mike,
>>>>>
>>>>> Thanks for the feedback! I replied inline.
>>>>> On 9/23/22 22:18, Yoav Weiss wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Sep 23, 2022 at 3:15 PM Mike Taylor  
>>>>> wrote:
>>>>>
>>>>>> Hi Byungwoo,
>>>>>>
>>>>>> On 9/23/22 4:34 AM, Byungwoo Lee wrote:
>>>>>>
>>>>>> Contact emails bl...@igalia.com
>>>>>>
>>>>>> Specification 
>>>>>> https://drafts.csswg.org/css-conditional-4/#support-definition-ext
>>>>>>
>>>>>> Summary 
>>>>>>
>>>>>> Some functional selectors are parsed forgivingly. (e.g. :is(), 
>>>>>> :has()) If an argument of the functional selectors is unknown or 
>>>>>> invalid, 
>>>>>> the argument is dropped but the selector itself is not invalidated. To 
>>>>>> provide a way of detecting the unknown or invalid arguments in those 
>>>>>> functional selectors, this feature applies the CSS Working Group issue 
>>>>>> resolution: - @supports uses non-forgiving parsing for all selectors (
>>>>>> https://github.com/w3c/csswg-drafts/issues/7280#issuecomment-1143852187
>>>>>> )
>>>>>>
>>>>>> Am I understanding correctly that content that now uses a functional 
>>>>> selector argument that's invalid may break as a result of this?
>>>>> If so, do we have usecounters to that effect?
>>>>>
>>>>> Yes it can change the previous behavior.
>>>>>
>>>>> This changes the selector parsing behavior only for the selectors 
>>>>> inside @supports selector().
>>>>>
>>>>> So if authors expected true for '@supports 
>>>>> selector(:is(:some-invalid-selector))', this feature will break it 
>>>>> because 
>>>>> the return value will be changed to false after this feature is enabled.
>>>>>
>>>>> I'm not sure that we have the usecounters of the case: counting drop 
>>>>> of invalid selector inside @supports selector.
>>>>>
>>>>> If it doesn't exists but it is needed, I think we can add it. Will it 
>>>>> be better to add it to get use counters before ship it?
>>>>>
>>>>
>>>> Yeah, knowing the order of magnitude of potential breakage would be 
>>>> good.  
>>>>
>>>> I landed a CL to add the use counter:
>>>>
>>>> https://chromiumdash.appspot.com/commit/d060459d174c468a78d69d4e2a12925e0e7ab216
>>>>  
>>>>
>>>> It counts the drop of invalid selector while forgiving selector parsing 
>>>> inside @supports selector(). We can see the stats with 
>>>> CSSAtSupportsDropInvalidWhileForgivingParsing(4361):
>>>> https://chromestatus.com/metrics/feature/timeline/popularity/4361
>>>>
>>>> This will be in 108 version so hopefully we can get the use counter 
>>>>

Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Byungwoo Lee]

Hello Yoav,

Chrome status shows the number from stable now.

I checked these metrics.
- https://chromestatus.com/metrics/feature/timeline/popularity/4361 
(CSSAtSupportsDropInvalidWhileForgivingParsing)
- https://chromestatus.com/metrics/feature/timeline/popularity/976 
(CSSAtRuleSupports)

According to the above metrics, some pages will be affected by this feature 
but it seems to be a relatively small fraction:
- Only 0.50 % of page loads are dropping invalid selector while parsing 
forgiving selector inside '@supports selector()'.
- 41.10% of page loads are using '@supports', but only 1.21% (0.5/41.1) of 
the page loads are dropping invalid selector while parsing forgiving 
selector inside '@supports selector()'.
- Less than 0.01 % of top sites are dropping invalid selector while parsing 
forgiving selector inside '@supports selector()'.
- 50.89% of top URLs are using '@supports', but less than 0.02% 
(0.01/50.89) of the URLs are dropping invalid selector while parsing 
forgiving selector inside '@supports selector()'.

Can we move forward based on this? Or should I check another number?

2022년 12월 10일 토요일 오전 1시 26분 57초 UTC+9에 Byungwoo Lee님이 작성:

> Hello,
>
> The 108 branch is shipping to stable now, but the numbers from stable 
> doesn't seems to be applied to the ChromeStatus stats yet. It seems that 
> the stable numbers will be applied at Jan. 1st.
> - https://chromestatus.com/metrics/feature/timeline/popularity/4361
>
> I'll reschedule the feature release to 112 so that we can revisit this 
> thread when we can get the numbers from stable.
>
> Thank you!
>
> p.s. 1
> This feature is not related to :has() anymore since :has() is now 
> unforgiving:
> - Issue resolution: 
> https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1341347244
> - CL : https://chromium-review.googlesource.com/c/chromium/src/+/4090967
> This feature only affects :is()/:where() inside @supports.
>
> p.s. 2
> Once I get the stable number, I'll provide a comparison of these two 
> numbers that I can get from the ChromeStatus stats:
> - Percentage of page loads that drop invalid while forgiving parsing 
> inside @supports selector
>   (https://chromestatus.com/metrics/feature/timeline/popularity/4361)
> - Percentage of page loads that use @supports rule
>   (https://chromestatus.com/metrics/feature/timeline/popularity/976)
>
> The comparison doesn't prove anything, but I think we can at least guess 
> how much the @supports change affects the existing behavior:
> Assuming the current numbers in the above links are from stable, about 40% 
> of the loaded pages use @supports rule, but only 0.002% of the loaded pages 
> hit the case of dropping invalid selector while forgiving selector parsing 
> inside @supports. By simply comparing the numbers, I think we can say that 
> 1/2 of the @supports rule usages will be affected by the feature.
>
> 2022년 10월 10일 월요일 오후 11시 18분 41초 UTC+9에 Byungwoo Lee님이 작성:
>
>> To continue this thread after getting the stable Chrome's use counter, I 
>> changed the estimated milestone of this feature from 109 to 111.
>> I'll share the use counter after the version 108 released.
>>
>> Thank you!
>>
>> 2022년 9월 29일 목요일 오전 11시 52분 43초 UTC+9에 Byungwoo Lee님이 작성:
>>
>>>
>>> On 9/27/22 10:07, Byungwoo Lee wrote:
>>>
>>>
>>> On 9/24/22 00:40, Yoav Weiss wrote:
>>>
>>>
>>>
>>> On Fri, Sep 23, 2022 at 5:25 PM Byungwoo Lee  wrote:
>>>
>>>> Hello Yoav and Mike,
>>>>
>>>> Thanks for the feedback! I replied inline.
>>>> On 9/23/22 22:18, Yoav Weiss wrote:
>>>>
>>>>
>>>>
>>>> On Fri, Sep 23, 2022 at 3:15 PM Mike Taylor  
>>>> wrote:
>>>>
>>>>> Hi Byungwoo,
>>>>>
>>>>> On 9/23/22 4:34 AM, Byungwoo Lee wrote:
>>>>>
>>>>> Contact emails bl...@igalia.com
>>>>>
>>>>> Specification 
>>>>> https://drafts.csswg.org/css-conditional-4/#support-definition-ext
>>>>>
>>>>> Summary 
>>>>>
>>>>> Some functional selectors are parsed forgivingly. (e.g. :is(), :has()) 
>>>>> If an argument of the functional selectors is unknown or invalid, the 
>>>>> argument is dropped but the selector itself is not invalidated. To 
>>>>> provide 
>>>>> a way of detecting the unknown or invalid arguments in those functional 
>>>>> selectors, this feature applies the CSS Working Group issue resolution: - 
>>>>> @supports uses non-forgiving parsing for all selectors (
>>>>> https://github.com/

Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Byungwoo Lee]

Hello,

The 108 branch is shipping to stable now, but the numbers from stable 
doesn't seems to be applied to the ChromeStatus stats yet. It seems that 
the stable numbers will be applied at Jan. 1st.
- https://chromestatus.com/metrics/feature/timeline/popularity/4361

I'll reschedule the feature release to 112 so that we can revisit this 
thread when we can get the numbers from stable.

Thank you!

p.s. 1
This feature is not related to :has() anymore since :has() is now 
unforgiving:
- Issue resolution: 
https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1341347244
- CL : https://chromium-review.googlesource.com/c/chromium/src/+/4090967
This feature only affects :is()/:where() inside @supports.

p.s. 2
Once I get the stable number, I'll provide a comparison of these two 
numbers that I can get from the ChromeStatus stats:
- Percentage of page loads that drop invalid while forgiving parsing inside 
@supports selector
  (https://chromestatus.com/metrics/feature/timeline/popularity/4361)
- Percentage of page loads that use @supports rule
  (https://chromestatus.com/metrics/feature/timeline/popularity/976)

The comparison doesn't prove anything, but I think we can at least guess 
how much the @supports change affects the existing behavior:
Assuming the current numbers in the above links are from stable, about 40% 
of the loaded pages use @supports rule, but only 0.002% of the loaded pages 
hit the case of dropping invalid selector while forgiving selector parsing 
inside @supports. By simply comparing the numbers, I think we can say that 
1/2 of the @supports rule usages will be affected by the feature.

2022년 10월 10일 월요일 오후 11시 18분 41초 UTC+9에 Byungwoo Lee님이 작성:

> To continue this thread after getting the stable Chrome's use counter, I 
> changed the estimated milestone of this feature from 109 to 111.
> I'll share the use counter after the version 108 released.
>
> Thank you!
>
> 2022년 9월 29일 목요일 오전 11시 52분 43초 UTC+9에 Byungwoo Lee님이 작성:
>
>>
>> On 9/27/22 10:07, Byungwoo Lee wrote:
>>
>>
>> On 9/24/22 00:40, Yoav Weiss wrote:
>>
>>
>>
>> On Fri, Sep 23, 2022 at 5:25 PM Byungwoo Lee  wrote:
>>
>>> Hello Yoav and Mike,
>>>
>>> Thanks for the feedback! I replied inline.
>>> On 9/23/22 22:18, Yoav Weiss wrote:
>>>
>>>
>>>
>>> On Fri, Sep 23, 2022 at 3:15 PM Mike Taylor  
>>> wrote:
>>>
>>>> Hi Byungwoo,
>>>>
>>>> On 9/23/22 4:34 AM, Byungwoo Lee wrote:
>>>>
>>>> Contact emails bl...@igalia.com
>>>>
>>>> Specification 
>>>> https://drafts.csswg.org/css-conditional-4/#support-definition-ext
>>>>
>>>> Summary 
>>>>
>>>> Some functional selectors are parsed forgivingly. (e.g. :is(), :has()) 
>>>> If an argument of the functional selectors is unknown or invalid, the 
>>>> argument is dropped but the selector itself is not invalidated. To provide 
>>>> a way of detecting the unknown or invalid arguments in those functional 
>>>> selectors, this feature applies the CSS Working Group issue resolution: - 
>>>> @supports uses non-forgiving parsing for all selectors (
>>>> https://github.com/w3c/csswg-drafts/issues/7280#issuecomment-1143852187
>>>> )
>>>>
>>>> Am I understanding correctly that content that now uses a functional 
>>> selector argument that's invalid may break as a result of this?
>>> If so, do we have usecounters to that effect?
>>>
>>> Yes it can change the previous behavior.
>>>
>>> This changes the selector parsing behavior only for the selectors inside 
>>> @supports selector().
>>>
>>> So if authors expected true for '@supports 
>>> selector(:is(:some-invalid-selector))', this feature will break it because 
>>> the return value will be changed to false after this feature is enabled.
>>>
>>> I'm not sure that we have the usecounters of the case: counting drop of 
>>> invalid selector inside @supports selector.
>>>
>>> If it doesn't exists but it is needed, I think we can add it. Will it be 
>>> better to add it to get use counters before ship it?
>>>
>>
>> Yeah, knowing the order of magnitude of potential breakage would be 
>> good.  
>>
>> I landed a CL to add the use counter:
>>
>> https://chromiumdash.appspot.com/commit/d060459d174c468a78d69d4e2a12925e0e7ab216
>>  
>>
>> It counts the drop of invalid selector while forgiving selector parsing 
>> inside @supports selector(). We can see the stats with 
>> CSSAtSupportsDropInvalidWh

Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Byungwoo Lee]

To continue this thread after getting the stable Chrome's use counter, I 
changed the estimated milestone of this feature from 109 to 111.
I'll share the use counter after the version 108 released.

Thank you!

2022년 9월 29일 목요일 오전 11시 52분 43초 UTC+9에 Byungwoo Lee님이 작성:

>
> On 9/27/22 10:07, Byungwoo Lee wrote:
>
>
> On 9/24/22 00:40, Yoav Weiss wrote:
>
>
>
> On Fri, Sep 23, 2022 at 5:25 PM Byungwoo Lee  wrote:
>
>> Hello Yoav and Mike,
>>
>> Thanks for the feedback! I replied inline.
>> On 9/23/22 22:18, Yoav Weiss wrote:
>>
>>
>>
>> On Fri, Sep 23, 2022 at 3:15 PM Mike Taylor  wrote:
>>
>>> Hi Byungwoo,
>>>
>>> On 9/23/22 4:34 AM, Byungwoo Lee wrote:
>>>
>>> Contact emails bl...@igalia.com
>>>
>>> Specification 
>>> https://drafts.csswg.org/css-conditional-4/#support-definition-ext
>>>
>>> Summary 
>>>
>>> Some functional selectors are parsed forgivingly. (e.g. :is(), :has()) 
>>> If an argument of the functional selectors is unknown or invalid, the 
>>> argument is dropped but the selector itself is not invalidated. To provide 
>>> a way of detecting the unknown or invalid arguments in those functional 
>>> selectors, this feature applies the CSS Working Group issue resolution: - 
>>> @supports uses non-forgiving parsing for all selectors (
>>> https://github.com/w3c/csswg-drafts/issues/7280#issuecomment-1143852187)
>>>
>>> Am I understanding correctly that content that now uses a functional 
>> selector argument that's invalid may break as a result of this?
>> If so, do we have usecounters to that effect?
>>
>> Yes it can change the previous behavior.
>>
>> This changes the selector parsing behavior only for the selectors inside 
>> @supports selector().
>>
>> So if authors expected true for '@supports 
>> selector(:is(:some-invalid-selector))', this feature will break it because 
>> the return value will be changed to false after this feature is enabled.
>>
>> I'm not sure that we have the usecounters of the case: counting drop of 
>> invalid selector inside @supports selector.
>>
>> If it doesn't exists but it is needed, I think we can add it. Will it be 
>> better to add it to get use counters before ship it?
>>
>
> Yeah, knowing the order of magnitude of potential breakage would be good.  
>
> I landed a CL to add the use counter:
>
> https://chromiumdash.appspot.com/commit/d060459d174c468a78d69d4e2a12925e0e7ab216
>  
>
> It counts the drop of invalid selector while forgiving selector parsing 
> inside @supports selector(). We can see the stats with 
> CSSAtSupportsDropInvalidWhileForgivingParsing(4361):
> https://chromestatus.com/metrics/feature/timeline/popularity/4361
>
> This will be in 108 version so hopefully we can get the use counter after 
> the version is released.
>
>- beta (Oct 27)
>- stable (Nov 29) 
>
> I'll share the stats when it released.
>
> Thanks!
>
>
>>>
>>> Blink component Blink 
>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>
>>>
>>> TAG review 
>>>
>>> TAG review status Not applicable
>>>
>>> Can you expand on why you think a TAG review is not needed here?
>>>
>> I thought that we don't need TAG review and the reason was
>>
>> - This is already specified in the spec:
>> https://drafts.csswg.org/css-conditional-4/#support-definition-ext 
>> <https://drafts.csswg.org/css-conditional-4/#support-definition-ext>
>>
>> - Firefox already landed it:
>>   https://bugzilla.mozilla.org/show_bug.cgi?id=1789248
>>
>> Will it be better to change the TAG review status to 'Pending'?
>>
>>
>>> Risks 
>>>
>>>
>>> Interoperability and Compatibility 
>>>
>>> *Gecko*: Shipped/Shipping 
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1789248
>>>
>>> *WebKit*: Positive
>>>
>>> *Web developers*: Positive
>>>
>>> Can you please link to these signals?
>>>
>>
>> WebKit:
>>
>> - Explained about this in a blog post:
>>   https://webkit.org/blog/13096/css-has-pseudo-class/
>>
>> Web developers:
>>
>> - Thumbs ups in the CSSWG issue:
>>https://github.com/w3c/csswg-drafts/issues/7280
>>
>> - jQuery applied the spec:
>>   https://github.com/jquery/jquery/pull/5107
>>
>>
>> Rego let me know what I missed (Thanks!), so I'm updating this.

Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Byungwoo Lee]

On 9/27/22 10:07, Byungwoo Lee wrote:



On 9/24/22 00:40, Yoav Weiss wrote:



On Fri, Sep 23, 2022 at 5:25 PM Byungwoo Lee  wrote:

Hello Yoav and Mike,

Thanks for the feedback! I replied inline.

On 9/23/22 22:18, Yoav Weiss wrote:



On Fri, Sep 23, 2022 at 3:15 PM Mike Taylor
 wrote:

Hi Byungwoo,

On 9/23/22 4:34 AM, Byungwoo Lee wrote:



Contact emails

b...@igalia.com


Specification

https://drafts.csswg.org/css-conditional-4/#support-definition-ext


Summary

Some functional selectors are parsed forgivingly. (e.g.
:is(), :has()) If an argument of the functional selectors
is unknown or invalid, the argument is dropped but the
selector itself is not invalidated. To provide a way of
detecting the unknown or invalid arguments in those
functional selectors, this feature applies the CSS Working
Group issue resolution: - @supports uses non-forgiving
parsing for all selectors

(https://github.com/w3c/csswg-drafts/issues/7280#issuecomment-1143852187)


Am I understanding correctly that content that now uses a
functional selector argument that's invalid may break as a
result of this?
If so, do we have usecounters to that effect?


Yes it can change the previous behavior.

This changes the selector parsing behavior only for the selectors
inside @supports selector().

So if authors expected true for '@supports
selector(:is(:some-invalid-selector))', this feature will break
it because the return value will be changed to false after this
feature is enabled.

I'm not sure that we have the usecounters of the case: counting
drop of invalid selector inside @supports selector.

If it doesn't exists but it is needed, I think we can add it.
Will it be better to add it to get use counters before ship it?


Yeah, knowing the order of magnitude of potential breakage would be 
good.

I landed a CL to add the use counter:
https://chromiumdash.appspot.com/commit/d060459d174c468a78d69d4e2a12925e0e7ab216 



It counts the drop of invalid selector while forgiving selector 
parsing inside @supports selector(). We can see the stats with 
CSSAtSupportsDropInvalidWhileForgivingParsing(4361):

https://chromestatus.com/metrics/feature/timeline/popularity/4361

This will be in 108 version so hopefully we can get the use counter 
after the version is released.


  * beta (Oct 27)
  * stable (Nov 29)

I'll share the stats when it released.

Thanks!




Blink component

Blink
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>


TAG review



TAG review status

Not applicable


Can you expand on why you think a TAG review is not needed here?


I thought that we don't need TAG review and the reason was

- This is already specified in the spec:
https://drafts.csswg.org/css-conditional-4/#support-definition-ext
<https://drafts.csswg.org/css-conditional-4/#support-definition-ext>

- Firefox already landed it:
https://bugzilla.mozilla.org/show_bug.cgi?id=1789248

Will it be better to change the TAG review status to 'Pending'?



Risks



Interoperability and Compatibility



/Gecko/:
Shipped/Shippinghttps://bugzilla.mozilla.org/show_bug.cgi?id=1789248

/WebKit/: Positive

/Web developers/: Positive

Can you please link to these signals?



WebKit:

- Explained about this in a blog post:
https://webkit.org/blog/13096/css-has-pseudo-class/

Web developers:

- Thumbs ups in the CSSWG issue:
https://github.com/w3c/csswg-drafts/issues/7280

- jQuery applied the spec:
https://github.com/jquery/jquery/pull/5107



Rego let me know what I missed (Thanks!), so I'm updating this.

This specification change has been implemented in WebKit as well as Firefox:
https://bugs.webkit.org/show_bug.cgi?id=244808

I updated the 'Safari views' and 'Tag review' in the chromestatus 
accordingly.



*WebKit:* Shipped/Shipping https://bugs.webkit.org/show_bug.cgi?id=244808


*Tag review*
No TAG review
- This is already specified in the spec:
https://drafts.csswg.org/css-conditional-4/#support-definition-ext
- Firefox and WebKit already implemented it:
https://bugzilla.mozilla.org/show_bug.cgi?id=1789248
https://bugs.webkit.org/show_bug.cgi?id=244808


*Tag review status*
pending


Could this update affect the shipping decisions?


thanks,
Mike


-- 
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

htt

Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Byungwoo Lee]

On 9/24/22 00:40, Yoav Weiss wrote:



On Fri, Sep 23, 2022 at 5:25 PM Byungwoo Lee  wrote:

Hello Yoav and Mike,

Thanks for the feedback! I replied inline.

On 9/23/22 22:18, Yoav Weiss wrote:



On Fri, Sep 23, 2022 at 3:15 PM Mike Taylor
 wrote:

Hi Byungwoo,

On 9/23/22 4:34 AM, Byungwoo Lee wrote:



Contact emails

b...@igalia.com


Specification

https://drafts.csswg.org/css-conditional-4/#support-definition-ext


Summary

Some functional selectors are parsed forgivingly. (e.g.
:is(), :has()) If an argument of the functional selectors is
unknown or invalid, the argument is dropped but the selector
itself is not invalidated. To provide a way of detecting the
unknown or invalid arguments in those functional selectors,
this feature applies the CSS Working Group issue resolution:
- @supports uses non-forgiving parsing for all selectors

(https://github.com/w3c/csswg-drafts/issues/7280#issuecomment-1143852187)


Am I understanding correctly that content that now uses a
functional selector argument that's invalid may break as a result
of this?
If so, do we have usecounters to that effect?


Yes it can change the previous behavior.

This changes the selector parsing behavior only for the selectors
inside @supports selector().

So if authors expected true for '@supports
selector(:is(:some-invalid-selector))', this feature will break it
because the return value will be changed to false after this
feature is enabled.

I'm not sure that we have the usecounters of the case: counting
drop of invalid selector inside @supports selector.

If it doesn't exists but it is needed, I think we can add it. Will
it be better to add it to get use counters before ship it?


Yeah, knowing the order of magnitude of potential breakage would be good.

I landed a CL to add the use counter:
https://chromiumdash.appspot.com/commit/d060459d174c468a78d69d4e2a12925e0e7ab216 



It counts the drop of invalid selector while forgiving selector parsing 
inside @supports selector(). We can see the stats with 
CSSAtSupportsDropInvalidWhileForgivingParsing(4361):

https://chromestatus.com/metrics/feature/timeline/popularity/4361

This will be in 108 version so hopefully we can get the use counter 
after the version is released.


 * beta (Oct 27)
 * stable (Nov 29)

I'll share the stats when it released.

Thanks!




Blink component

Blink
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>


TAG review



TAG review status

Not applicable


Can you expand on why you think a TAG review is not needed here?


I thought that we don't need TAG review and the reason was

- This is already specified in the spec:
https://drafts.csswg.org/css-conditional-4/#support-definition-ext
<https://drafts.csswg.org/css-conditional-4/#support-definition-ext>

- Firefox already landed it:
https://bugzilla.mozilla.org/show_bug.cgi?id=1789248

Will it be better to change the TAG review status to 'Pending'?



Risks



Interoperability and Compatibility



/Gecko/:
Shipped/Shippinghttps://bugzilla.mozilla.org/show_bug.cgi?id=1789248

/WebKit/: Positive

/Web developers/: Positive

Can you please link to these signals?



WebKit:

- Explained about this in a blog post:
https://webkit.org/blog/13096/css-has-pseudo-class/

Web developers:

- Thumbs ups in the CSSWG issue:
https://github.com/w3c/csswg-drafts/issues/7280

- jQuery applied the spec:
https://github.com/jquery/jquery/pull/5107



thanks,
Mike


-- 
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/b03b90af-3911-40b4-dd6f-b12764826cf1%40chromium.org

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b03b90af-3911-40b4-dd6f-b12764826cf1%40chromium.org?utm_medium=email_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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6742d462-388f-8bda-8063-314203d4a143%40igalia.com.

Re: [blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Byungwoo Lee]

Hello Yoav and Mike,

Thanks for the feedback! I replied inline.

On 9/23/22 22:18, Yoav Weiss wrote:



On Fri, Sep 23, 2022 at 3:15 PM Mike Taylor  
wrote:


Hi Byungwoo,

On 9/23/22 4:34 AM, Byungwoo Lee wrote:



Contact emails

b...@igalia.com


Specification

https://drafts.csswg.org/css-conditional-4/#support-definition-ext


Summary

Some functional selectors are parsed forgivingly. (e.g. :is(),
:has()) If an argument of the functional selectors is unknown or
invalid, the argument is dropped but the selector itself is not
invalidated. To provide a way of detecting the unknown or invalid
arguments in those functional selectors, this feature applies the
CSS Working Group issue resolution: - @supports uses
non-forgiving parsing for all selectors
(https://github.com/w3c/csswg-drafts/issues/7280#issuecomment-1143852187)

Am I understanding correctly that content that now uses a functional 
selector argument that's invalid may break as a result of this?

If so, do we have usecounters to that effect?


Yes it can change the previous behavior.

This changes the selector parsing behavior only for the selectors inside 
@supports selector().


So if authors expected true for '@supports 
selector(:is(:some-invalid-selector))', this feature will break it 
because the return value will be changed to false after this feature is 
enabled.


I'm not sure that we have the usecounters of the case: counting drop of 
invalid selector inside @supports selector.


If it doesn't exists but it is needed, I think we can add it. Will it be 
better to add it to get use counters before ship it?





Blink component

Blink
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink>


TAG review



TAG review status

Not applicable


Can you expand on why you think a TAG review is not needed here?


I thought that we don't need TAG review and the reason was

- This is already specified in the spec:
https://drafts.csswg.org/css-conditional-4/#support-definition-ext

- Firefox already landed it:
https://bugzilla.mozilla.org/show_bug.cgi?id=1789248

Will it be better to change the TAG review status to 'Pending'?



Risks



Interoperability and Compatibility



/Gecko/:
Shipped/Shippinghttps://bugzilla.mozilla.org/show_bug.cgi?id=1789248

/WebKit/: Positive

/Web developers/: Positive

Can you please link to these signals?



WebKit:

- Explained about this in a blog post:
https://webkit.org/blog/13096/css-has-pseudo-class/

Web developers:

- Thumbs ups in the CSSWG issue:
https://github.com/w3c/csswg-drafts/issues/7280

- jQuery applied the spec:
https://github.com/jquery/jquery/pull/5107



thanks,
Mike


-- 
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/b03b90af-3911-40b4-dd6f-b12764826cf1%40chromium.org

<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b03b90af-3911-40b4-dd6f-b12764826cf1%40chromium.org?utm_medium=email_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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b0b38344-3a85-a30f-1a12-fd897108c340%40igalia.com.

[blink-dev] Intent to Ship: CSS @supports : Always non-forgiving parsing

[Byungwoo Lee]

   Contact emails

b...@igalia.com


   Specification

https://drafts.csswg.org/css-conditional-4/#support-definition-ext


   Summary

Some functional selectors are parsed forgivingly. (e.g. :is(), :has()) 
If an argument of the functional selectors is unknown or invalid, the 
argument is dropped but the selector itself is not invalidated. To 
provide a way of detecting the unknown or invalid arguments in those 
functional selectors, this feature applies the CSS Working Group issue 
resolution: - @supports uses non-forgiving parsing for all selectors 
(https://github.com/w3c/csswg-drafts/issues/7280#issuecomment-1143852187)




   Blink component

Blink 


   TAG review



   TAG review status

Not applicable


   Risks



   Interoperability and Compatibility



/Gecko/: 
Shipped/Shippinghttps://bugzilla.mozilla.org/show_bug.cgi?id=1789248


/WebKit/: Positive

/Web developers/: Positive

/Other signals/:


   WebView application risks

No



   Debuggability

This can be tested by calling 'CSS.supports()' in the DevTools 
Console window.




   Will this feature be supported on all six Blink platforms
   (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes


   Is this feature fully tested byweb-platform-tests
   
?

Yes

 * 
https://wpt.fyi/results/css/css-conditional/at-supports-selector-detecting-invalid-in-forgiving-argument.html
 * 
https://wpt.fyi/results/css/css-conditional/js/CSS-supports-selector-detecting-invalid-in-forgiving-argument.html


   Flag name



   Requires code in //chrome?

False


   Launch bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1359396


   Estimated milestones

109



   Anticipated spec changes

The issue is resolved and closed : 
https://github.com/w3c/csswg-drafts/issues/7280




   Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6177049203441664

This intent message was generated byChrome Platform Status 
.


--
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/5a9733cb-d530-0e76-45a8-08423dfdbd56%40igalia.com.

Re: [blink-dev] Intent to Ship : :has() pseudo class

[Byungwoo Lee]

Thank you for checking the issue and sorry for not being able to prevent it 
in advance.

I missed the risk of conflicting with JQuery's :has() implementation. I 
apologize for not checking enough.

I made a CL to avoid current JQuery conflict by following the WebKit 
behavior:
 - https://chromium-review.googlesource.com/c/chromium/src/+/3868781

After the CL merged, these web-platform-tests results will be same with 
WebKit:
- https://wpt.fyi/results/css/selectors/has-error-recovery.html
- 
https://wpt.fyi/results/css/selectors/parsing/parse-has-disallow-nesting-has-inside-has.html
- https://wpt.fyi/results/css/selectors/parsing/parse-has.html

If it looks OK, I'll try to merge it asap.

2022년 9월 2일 금요일 오후 9시 52분 35초 UTC+9에 Rune Lillesveen님이 작성:

> On Fri, Sep 2, 2022 at 2:39 PM Yoav Weiss  wrote:
>
>>
>>
>> On Fri, Sep 2, 2022 at 2:19 PM Rune Lillesveen  
>> wrote:
>>
>>> On Fri, Sep 2, 2022 at 1:37 PM Yoav Weiss  wrote:
>>>
>>>> Thanks for the update! Given that this is something that web developers 
>>>> have been using (as a polyfill, but still) for a lng while, I'm 
>>>> somewhat skeptical that we can get away with the spec as currently written.
>>>> As we can't have use-counters for things passed as jquery selectors, I 
>>>> wonder if an HTTPArchive and a GitHub search can reveal how widespread 
>>>> this 
>>>> is.
>>>>
>>>> But I suspect this is a "revert first and ask questions later" kind of 
>>>> situation. Unfortunately, it seems like this would require a code update, 
>>>> as the flag is not propagated to a Chromium feature flag 
>>>> <https://source.chromium.org/search?q=CSSPseudoHas%20-f:out==chromium%2Fchromium%2Fsrc>
>>>>  AFAICT.
>>>>
>>>
>>> That is correct.
>>>
>>> It could be that the best way short term is to change the implementation 
>>> to not allow forgiving selectors lists. Authors should be able to get the 
>>> same forgiving effect for :has() sprinkling :is() at appropriate places.
>>>
>>
>> Given that a code change is required anyways, that sounds reasonable..
>>
>
> New update about the WebKit implementation:
>
> https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1235450787
>
> They _do_ support a forgiving selector list, with a small twist that if 
> all selectors are invalid and end up with an empty :has(), the selector is 
> dropped.
>
>  
>>
>>>
>>> Slightly longer term, the spec issue for possibly changing it is here: 
>>> https://github.com/w3c/csswg-drafts/issues/7676
>>>
>>> On Fri, Sep 2, 2022 at 1:11 PM Rune Lillesveen  
>>>> wrote:
>>>>
>>>>> On Fri, Sep 2, 2022 at 1:09 PM Rune Lillesveen  
>>>>> wrote:
>>>>>
>>>>>> On Fri, Sep 2, 2022 at 11:40 AM Rune Lillesveen  
>>>>>> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> We have an incoming issue for jQuery that seems pretty serious for 
>>>>>>> them:
>>>>>>>
>>>>>>
>>>>>> An update on the impact for jQuery:
>>>>>>
>>>>>> https://github.com/jquery/jquery/issues/5098#issuecomment-1235351545
>>>>>>
>>>>>
>>>>> There was an issue filed for the CSSWG 
>>>>> https://github.com/w3c/csswg-drafts/issues/7676
>>>>>
>>>>> https://crbug.com/1358953
>>>>>>>
>>>>>>> The problem is that jQuery uses the native implementation of :has() 
>>>>>>> when present, but the feature detection detects support for other 
>>>>>>> custom 
>>>>>>> jQuery selectors inside :has() because of :has() accepting forgiving 
>>>>>>> selectors.
>>>>>>>
>>>>>>> It should be possible to fix this for jQuery, but the problem is for 
>>>>>>> existing content which relies on this feature detection.
>>>>>>>
>>>>>>> The reason why this was not detected when Safari shipped :has(), is 
>>>>>>> that Safari does not accept  like the 
>>>>>>> spec says. I have filed 
>>>>>>> https://bugs.webkit.org/show_bug.cgi?id=244708 against WebKit.
>>>>>>>
>>>>>>> On Thu, Jun 2, 2022 at 5:57 PM Chris Harrelson  
>>>>>>> wrote:
>>&g

Re: [blink-dev] Intent to Ship : :has() pseudo class

[Byungwoo Lee]

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!

2022년 5월 20일 금요일 오후 2시 49분 3초 UTC+9에 bl...@igalia.com님이 작성:

> 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  wrote:
>>
>>>
>>> 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) 
>>>>   - ':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 
>>>

Re: [blink-dev] Intent to Ship : :has() pseudo class

[Byungwoo Lee]

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  wrote:


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 w

Re: [blink-dev] Intent to Ship : :has() pseudo class

[Byungwoo Lee]

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  wrote:
>
>>
>> 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) 
>>>   - ':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 con

Re: [blink-dev] Intent to Ship : :has() pseudo class

[Byungwoo Lee]

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.

Re: [blink-dev] Intent to Ship : :has() pseudo class

[Byungwoo Lee]

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 blink-dev+unsubscr...@chromium.org.
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.