Hey another nice bonus with this excellent change is: the YouTube desktop website no longer has to use their dreadful custom scrollbar (see attached screenshot) which has quite a few issues and downsides compared to the standard Chrome scrollbar. Finally they can do away with that and just use the standard Chrome scrollbar! If anyone at Google or YouTube is reading this, please let the relevant people on the YouTube desktop team know![image: Youtubescrollbar.png]
On Tuesday, March 26, 2024 at 10:41:43 PM UTC-4 Domenic Denicola wrote: > LGTM3 > > On Wednesday, March 27, 2024 at 4:45:08 AM UTC+9 Mike Taylor wrote: > >> LGTM2 >> On 3/26/24 1:25 PM, Yoav Weiss (@Shopify) wrote: >> >> LGTM1 once the fix >> <https://chromium-review.googlesource.com/c/chromium/src/+/5386749> to >> the above issue lands. >> >> On Monday, March 18, 2024 at 7:56:52 PM UTC+1 yshal...@microsoft.com >> wrote: >> >>> Yes, I believe the bug [1] is a blocker. >>> >>> [1] https://issues.chromium.org/issues/328102503. >>> >>> On Monday, March 18, 2024 at 1:51:43 AM UTC-7 yoav...@chromium.org >>> wrote: >>> >>>> Great to see a positive position from Mozilla on this. >>>> >>>> Is the above mentioned bug a blocker here? >>>> >>>> On Friday, March 8, 2024 at 12:52:58 AM UTC+1 yshal...@microsoft.com >>>> wrote: >>>> >>>>> Thanks for taking a look and your feedback! Please let me know if you >>>>> have any other questions or concerns. >>>>> On Thursday, March 7, 2024 at 3:23:02 PM UTC-8 William Smith wrote: >>>>> >>>>>> Thank you! And just to be clear, I personally don't see it as a >>>>>> problem at all, I was only curious. I actually think this should have >>>>>> shipped along with dark mode back in 2019, but better late than never. >>>>>> >>>>>> On Thursday, March 7, 2024 at 5:22:14 PM UTC-5 Yaroslav Shalivskyy >>>>>> wrote: >>>>>> >>>>>>> Hello William! Thank you for selfhosting the feature! >>>>>>> >>>>>>> For the pages you mentioned, the feature is working as indented. If >>>>>>> you enable the dark mode in OS settings (e.g., refer to the screenshot >>>>>>> attached from the Windows device), root scrollbars will follow the OS >>>>>>> settings unless page authors have explicitly specified page’s supported >>>>>>> color schemes. >>>>>>> >>>>>>> However, I recently discovered a bug related to Chrome browser >>>>>>> Appearance > Mode setting. The setting doesn't impact the calculation >>>>>>> of >>>>>>> web contents' used color scheme, resulting in inconsistent behavior. >>>>>>> For >>>>>>> more details, please see: [UsedColorSchemeRootScrollbars] Root >>>>>>> scrollbars are dark when the browser color theme setting is "Light" and >>>>>>> the >>>>>>> OS theme settings is "Dark" [328102503] - Chromium >>>>>>> <https://issues.chromium.org/issues/328102503>. I am currently >>>>>>> prioritizing work on the CL to fix this issue. >>>>>>> On Wednesday, March 6, 2024 at 8:54:37 PM UTC-8 William Smith wrote: >>>>>>> >>>>>>>> Apologies if this isn't the correct place to ask this but I have >>>>>>>> this working in Chrome Canary and as fantastic as it is, they behavior >>>>>>>> on >>>>>>>> some websites has me confused: on >>>>>>>> https://en.wikipedia.org/wiki/Main_Page and amazon.com the >>>>>>>> scrollbar is dark, but neither of those webpages have a dark mode in >>>>>>>> any >>>>>>>> way. Is this a bug in the feature or is it working as intended? >>>>>>>> >>>>>>>> On Tuesday, March 5, 2024 at 5:33:33 PM UTC-5 Yaroslav Shalivskyy >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Mike and Daniel, thank you for the suggestions! >>>>>>>>> >>>>>>>>> I requested browser vendor positions as well as reviews for >>>>>>>>> chromestatus entry. >>>>>>>>> >>>>>>>>> Mozilla: [css-color-adjust-1] Root non-overlay scrollbars used >>>>>>>>> color scheme · Issue #995 · mozilla/standards-positions (github.com) >>>>>>>>> <https://github.com/mozilla/standards-positions/issues/995> >>>>>>>>> WebKit: [css-color-adjust-1] Root non-overlay scrollbars used >>>>>>>>> color scheme · Issue #326 · WebKit/standards-positions (github.com) >>>>>>>>> <https://github.com/WebKit/standards-positions/issues/326> >>>>>>>>> >>>>>>>>> I updated the chromestatus entry with these links as well. >>>>>>>>> >>>>>>>>> On Monday, March 4, 2024 at 12:08:23 PM UTC-8 mike...@chromium.org >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Thanks for the summary of the experiment results on Edge - sounds >>>>>>>>>> positive. >>>>>>>>>> >>>>>>>>>> If this is purely a browser UI change, then we don't really need >>>>>>>>>> the blink-dev process at all. However, if we're relying on concepts >>>>>>>>>> defined >>>>>>>>>> in a CSSWG draft, and devs can change the outcome w/ some CSS (or >>>>>>>>>> maybe >>>>>>>>>> here, the lack of CSS to result in non-`normal` computed value...) >>>>>>>>>> it would >>>>>>>>>> be if there were interoperability in UI choices across browsers. I >>>>>>>>>> don't >>>>>>>>>> necessarily think we should block on the outcome, but requesting >>>>>>>>>> vendor >>>>>>>>>> positions could be useful. >>>>>>>>>> >>>>>>>>>> (and Daniel, if you scroll down a bit - I did ask about TAG and >>>>>>>>>> browser signals. :)) >>>>>>>>>> On 3/2/24 1:10 PM, Daniel Bratell wrote: >>>>>>>>>> >>>>>>>>>> Mike didn't refer to the TAG review or browser signals, but the >>>>>>>>>> review steps in chromestatus. The intent should request, privacy, >>>>>>>>>> security, >>>>>>>>>> enterprise, and the other steps there. >>>>>>>>>> >>>>>>>>>> I agree that this lives in the borderland between user agent UI >>>>>>>>>> and a web visible change so some shortcuts might be possible to >>>>>>>>>> motivate, >>>>>>>>>> but you still need to click the the appropriate buttons in the >>>>>>>>>> chromestatus >>>>>>>>>> tool. >>>>>>>>>> >>>>>>>>>> /Daniel >>>>>>>>>> On 2024-03-01 21:10, 'Yaroslav Shalivskyy' via blink-dev wrote: >>>>>>>>>> >>>>>>>>>> Hello Mike, >>>>>>>>>> >>>>>>>>>> Thank you for taking a look! >>>>>>>>>> >>>>>>>>>> I am seeking consensus on how to approach the feature from a >>>>>>>>>> standardization perspective. I think the feature can be considered a >>>>>>>>>> browser UI change, which is why I haven't requested a TAG review >>>>>>>>>> or signals from other engines. However, I am open to doing so if >>>>>>>>>> necessary. >>>>>>>>>> >>>>>>>>>> I apologize for any confusion. We did the general experimentation >>>>>>>>>> in Edge (not the "origin trials" as I mentioned in the email). >>>>>>>>>> Retention >>>>>>>>>> reports were neutral, and we observed no regressions in scorecards. >>>>>>>>>> Also, >>>>>>>>>> we have not received any negative user feedback thus far. >>>>>>>>>> >>>>>>>>>> I am working on requesting reviews for my chromestatus entry. >>>>>>>>>> Thanks for pointing this out! >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Yaroslav >>>>>>>>>> >>>>>>>>>> On Friday, March 1, 2024 at 5:52:55 AM UTC-8 mike...@chromium.org >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Hi there, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Would you mind requesting reviews for the various review gates >>>>>>>>>>> in your chromestatus entry? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 2/29/24 4:12 PM, 'Yaroslav Shalivskyy' via blink-dev wrote: >>>>>>>>>>> >>>>>>>>>>> Contact emails >>>>>>>>>>> gerc...@microsoft.com, yshal...@microsoft.com >>>>>>>>>>> >>>>>>>>>>> Explainer >>>>>>>>>>> None >>>>>>>>>>> >>>>>>>>>>> Specification >>>>>>>>>>> https://www.w3.org/TR/css-color-adjust-1 >>>>>>>>>>> >>>>>>>>>>> Summary >>>>>>>>>>> >>>>>>>>>>> Makes the browser use the user's preferred color scheme to >>>>>>>>>>> render the viewport scrollbars if the value of "page’s supported >>>>>>>>>>> color >>>>>>>>>>> schemes" is 'normal' or not specified, and the computed value of >>>>>>>>>>> the >>>>>>>>>>> color-scheme for the root element is 'normal'. Viewport scrollbars >>>>>>>>>>> can be >>>>>>>>>>> considered to be outside the web content. Therefore, the user >>>>>>>>>>> agents should >>>>>>>>>>> honor the user's preferred color scheme when rendering viewport >>>>>>>>>>> scrollbars >>>>>>>>>>> if page authors have not explicitly specified support for color >>>>>>>>>>> schemes. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Blink component >>>>>>>>>>> Blink>Layout>Scrollbars >>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ELayout%3EScrollbars> >>>>>>>>>>> >>>>>>>>>>> TAG review >>>>>>>>>>> None >>>>>>>>>>> >>>>>>>>>>> TAG review status >>>>>>>>>>> Not applicable >>>>>>>>>>> >>>>>>>>>>> Any reason you think this is N/A, or have you just not requested >>>>>>>>>>> TAG review? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Risks >>>>>>>>>>> >>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>> >>>>>>>>>>> None >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> *Gecko*: No signal >>>>>>>>>>> >>>>>>>>>>> *WebKit*: No signal >>>>>>>>>>> >>>>>>>>>>> *Web developers*: No signals >>>>>>>>>>> >>>>>>>>>>> *Other signals*: >>>>>>>>>>> >>>>>>>>>>> Could we request signals please? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> WebView application risks >>>>>>>>>>> >>>>>>>>>>> *Does this intent deprecate or change behavior of existing APIs, >>>>>>>>>>> such that it has potentially high risk for Android WebView-based >>>>>>>>>>> applications?* >>>>>>>>>>> >>>>>>>>>>> None >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Debuggability >>>>>>>>>>> >>>>>>>>>>> None >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>>>>>>>> Yes >>>>>>>>>>> >>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>> ? >>>>>>>>>>> No >>>>>>>>>>> >>>>>>>>>>> Flag name on chrome://flags >>>>>>>>>>> None >>>>>>>>>>> >>>>>>>>>>> Finch feature name >>>>>>>>>>> UsedColorSchemeRootScrollbars >>>>>>>>>>> >>>>>>>>>>> Requires code in //chrome? >>>>>>>>>>> False >>>>>>>>>>> >>>>>>>>>>> Tracking bug >>>>>>>>>>> https://issues.chromium.org/issues/40259909 >>>>>>>>>>> >>>>>>>>>>> Measurement >>>>>>>>>>> Added a use counter UsedColorSchemeRootScrollbarsDark. The >>>>>>>>>>> counter tracks the number of users who have dark mode root >>>>>>>>>>> scrollbars due >>>>>>>>>>> to the feature. Adoption in Edge Stable population based on this >>>>>>>>>>> metric is >>>>>>>>>>> approximately 13%. >>>>>>>>>>> >>>>>>>>>>> Availability expectation >>>>>>>>>>> Initially available in Chromium browsers. >>>>>>>>>>> >>>>>>>>>>> Adoption expectation >>>>>>>>>>> This feature immediately affects specific use cases upon launch. >>>>>>>>>>> >>>>>>>>>>> Adoption plan >>>>>>>>>>> This feature has been through origin trials on Edge. Other >>>>>>>>>>> browsers adopt this feature to fix specific use cases. >>>>>>>>>>> >>>>>>>>>>> Any details or feedback you can share from the Origin Trial? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Non-OSS dependencies >>>>>>>>>>> >>>>>>>>>>> *Does the feature depend on any code or APIs outside the >>>>>>>>>>> Chromium open source repository and its open-source dependencies to >>>>>>>>>>> function?* >>>>>>>>>>> No. >>>>>>>>>>> >>>>>>>>>>> Estimated milestones >>>>>>>>>>> >>>>>>>>>>> Shipping on desktop >>>>>>>>>>> 124 >>>>>>>>>>> DevTrial on desktop >>>>>>>>>>> 121 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Anticipated spec changes >>>>>>>>>>> >>>>>>>>>>> *Open questions about a feature may be a source of future web >>>>>>>>>>> compat or interop issues. Please list open issues (e.g. links to >>>>>>>>>>> known >>>>>>>>>>> github issues in the project for the feature specification) whose >>>>>>>>>>> resolution may introduce web compat/interop risk (e.g., changing to >>>>>>>>>>> naming >>>>>>>>>>> or structure of the API in a non-backward-compatible way).* >>>>>>>>>>> None >>>>>>>>>>> >>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>> https://chromestatus.com/feature/5089486318075904 >>>>>>>>>>> >>>>>>>>>>> Links to previous Intent discussions >>>>>>>>>>> Intent to prototype: >>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/PH8PR00MB16366CA3D32D8ECE2C646C54A94D2%40PH8PR00MB1636.namprd00.prod.outlook.com >>>>>>>>>>> >>>>>>>>>>> This intent message was generated by Chrome Platform Status >>>>>>>>>>> <https://chromestatus.com/>. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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/LV3PR00MB17488611D88C9E41AC6A806BA95F2%40LV3PR00MB1748.namprd00.prod.outlook.com >>>>>>>>>>> >>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/LV3PR00MB17488611D88C9E41AC6A806BA95F2%40LV3PR00MB1748.namprd00.prod.outlook.com?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+...@chromium.org. >>>>>>>>>> To view this discussion on the web visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/34e66337-a227-4521-93bc-42317a1659b4n%40chromium.org >>>>>>>>>> >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/34e66337-a227-4521-93bc-42317a1659b4n%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/6c21b0a2-3f56-4f59-ba84-af630f03886en%40chromium.org.
