Intent to Ship: Used color scheme root scrollbars
Yaroslav Shalivskyy
Contact emails
Explainer
Specification
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
TAG review
TAG review status
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
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
Is this feature fully tested by web-platform-tests?
Flag name on chrome://flags
Finch feature name
Requires code in //chrome?
Tracking bug
Measurement
Availability expectation
Adoption expectation
Adoption plan
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?
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).
Link to entry on the Chrome Platform Status
Links to previous Intent discussions
Mike Taylor
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
Explainer
None
Specification
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
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:
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
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
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.
--
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.
Yaroslav Shalivskyy
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
Daniel Bratell
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
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.
Mike Taylor
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. :))
Yaroslav Shalivskyy
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)
WebKit: [css-color-adjust-1] Root non-overlay scrollbars used color scheme · Issue #326 · WebKit/standards-positions (github.com)
I updated the chromestatus entry with these links as well.
William Smith
Yaroslav Shalivskyy
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. I am currently prioritizing work on the CL to fix this issue.
William Smith
Yaroslav Shalivskyy
Yoav Weiss (@Shopify)
Yaroslav Shalivskyy
Yoav Weiss (@Shopify)
Mike Taylor
LGTM2
Domenic Denicola
William Smith
