I may be wrong, but AFAIU this feature will not be web-exposed (i.e. developers would not be able to tell through web APIs if it is or not enabled). Therefore, it seems like this feature doesn't have to go through the Blink process.
There may be other processes in order to land browser UI code upstream. I'm sure +Robert Flack <[email protected]> can help guide y'all through them. On Fri, Feb 16, 2024 at 1:01 AM 'Yaroslav Shalivskyy' via blink-dev < [email protected]> wrote: > Hello everyone! > > I think the feature can be considered a browser UI change, so I am > interested to gain consensus on how to approach the feature from > standardization point of view. I know +Robert Flack on a separate thread > suggested that root scrollbars can be considered to be outside the web > content in a way the other scrollbars are not. E.g. nothing usually draws > on top of root scrollbars or styles content around / behind them. > > Enabling the feature in Can/Dev/Beta/Stable as a part of experimentation > in Edge so far didn't have any negative reactions. > > I am looking forward to hearing your opinion on this! > > Thanks, > Yaroslav > > On Thursday, February 15, 2024 at 3:10:56 PM UTC-8 Yaroslav Shalivskyy > wrote: > >> Contact emails >> [email protected], [email protected] >> >> 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> >> >> Motivation >> >> Many web pages don't specify the support for light/dark color schemes >> using CSS "color-scheme" property or meta tags. In such a case, the used >> color scheme is light for scrollbars and other interactive UI elements >> despite the user preference set on the browser/OS level. Although the >> behavior is expected for elements which are part of the web content, >> viewport non-overlay scrollbars always stay on the side of the page and are >> treated by users as a part of the browser UI. The current behavior confuses >> users who have selected dark mode and expect viewport scrollbars to follow >> their choice. Edge users repeatedly reported the viewport scrollbars being >> light when dark mode is enabled. These are a few public feedback items: >> https://www.reddit.com/r/MicrosoftEdge/comments/xrf1wb/scrollbars_are_wh >> https://www.reddit.com/r/chrome/comments/lz0778/any_way_to_remove_or_turn_dark_ >> https://www.reddit.com/r/ArcBrowser/comments/18ldsj2/why_in_dark_mo >> Relevant Chromium and Mozilla issues: >> https://issues.chromium.org/issues/40155812 >> https://bugzilla.mozilla.org/show_bug.cgi?id=1859940 The feature doesn't >> impact developer APIs and still allows to control the color scheme for >> scrollbars and other controls. The new behavior makes the browser use the >> user’s preferred color-scheme to render viewport non-overlay scrollbars >> when page authors don’t specify the color scheme for the root element. >> >> >> Initial public proposal >> [css-color-adjust-1] Root viewport non-overlay scrollbars should follow >> the user's preferred color scheme by default · Issue #8603 · >> w3c/csswg-drafts (github.com) >> <https://github.com/w3c/csswg-drafts/issues/8603> >> >> TAG review >> None >> >> TAG review status >> Not applicable >> >> Risks >> >> >> Interoperability and Compatibility >> >> None >> >> >> *Gecko*: No signal >> >> *WebKit*: No signal >> >> *Web developers*: No signals >> >> *Other signals*: >> >> 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 >> >> >> 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 >> Runtime feature name: UsedColorSchemeRootScrollbars >> >> Finch feature name >> None >> >> Non-finch justification >> None >> >> Requires code in //chrome? >> False >> >> Tracking bug >> https://issues.chromium.org/issues/40259909 >> >> Estimated milestones >> >> No milestones specified >> >> >> Link to entry on the Chrome Platform Status >> https://chromestatus.com/feature/5089486318075904 >> >> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0151492b-2c9b-4875-94c4-df3e3f3ebe38n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0151492b-2c9b-4875-94c4-df3e3f3ebe38n%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/CAOmohS%2BD0zQLo0F%3DO%2BdfLUQg7HrEqZ4eVwpJDuR7-SXHyRNdKQ%40mail.gmail.com.
