Added missing links. 2023년 1월 6일 금요일 오전 12시 52분 25초 UTC+9에 Byungwoo Lee님이 작성:
> 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. > -------- [1] https://github.com/w3c/csswg-drafts/commit/3a2efb33d12f6667d6142e89609a982978b49223 [2] https://github.com/w3c/csswg-drafts/issues/7280 [3] https://github.com/w3c/csswg-drafts/issues/7676#issuecomment-1341347244 [4] https://chromium.googlesource.com/chromium/src/+/2b818b338146d89e524c4fabc2c6f7fd7776937a [5] https://chromiumdash.appspot.com/commit/7278cf3bf630c7791ba4b4885eb7da64dc16eab2 [6] It uses `@supports` like this: @supports not selector(:has()) { .woocommerce:has(> .woocommerce-MyAccount-navigation){ display:flex; justify-content:space-between } } I'm not sure but the `not` seems to be a workaround to make the block works. > 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/327b5fba-dd3d-403e-a042-257663d37a9an%40chromium.org.
