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)
- There are 2 sub cases:
- URLs using WordPress yootheme [1]
- URLs using jQuery `has()` [2]
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 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/20000 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 <[email protected]> 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 <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi Byungwoo,
>>>>>>
>>>>>> On 9/23/22 4:34 AM, Byungwoo Lee wrote:
>>>>>>
>>>>>> Contact emails [email protected]
>>>>>>
>>>>>> 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.
>>>>
>>>> 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 [email protected].
>>>>>> 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&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/fadf59d3-d092-4f78-8518-9dbf404ca63fn%40chromium.org.
