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 <bl...@igalia.com> 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 <mike...@chromium.org> >>>> 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. >>> >>> 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+...@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&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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fefe5994-78cb-4f68-8f1b-1c0d0efe0c55n%40chromium.org.
