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/84a7baa3-8416-43a8-b2c7-fb064bbc926fn%40chromium.org.
