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 <[email protected]> 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 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/CAL5BFfVc9FFVJm12UM%2Ba4VK%3DRqtKk%2B7MR1ybSMemrL9WE7n%3DhA%40mail.gmail.com.
