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 <bl...@igalia.com> 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 <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/de9784f1-6e60-4076-9a56-b3f02e9ab9b1n%40chromium.org.
