Intent to Prototype: Used color scheme root scrollbars

[Yaroslav Shalivskyy]

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

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)

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?

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.

[Yaroslav Shalivskyy]

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

[Yoav Weiss (@Shopify)]

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 can help guide y'all through them.

--
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/0151492b-2c9b-4875-94c4-df3e3f3ebe38n%40chromium.org.

[William Smith]

This is fantastic! Is there a flag for this?

[Yaroslav Shalivskyy]

"Therefore, it seems like this feature doesn't have to go through the Blink process."

Yoav, thank you for the feedback! Yeah, I am trying to clarify the process and get consensus for the next steps.

"This is fantastic! Is there a flag for this?"

Yes! William, you can enable the feature using the runtime flag: UsedColorSchemeRootScrollbars.
The feature doesn't have an "experimental" status yet so it can only be enabled via the command line.

[William Smith]

I tried that command line flag and it didn't work

[Yaroslav Shalivskyy]

William, thanks for the interest in the feature!

1. What platform are you using?
2. Did you try enabling dark mode in the OS settings?

I have recently merged the change to make the feature available as a part of Experimental Web Platform features flag (chrome://flags/#enable-experimental-web-platform-features). Feel free to check it out in Chrome Canary.