Intent to Ship: AccentColor and AccentColorText system colors

30 views
Skip to first unread message

Alexander Kyereboah

unread,
5:05 PM (2 hours ago) 5:05 PM
to blink-dev, alm...@microsoft.com
Contact emails
jar...@chromium.org, ort...@chromium.org, priy...@microsoft.com, akyer...@microsoft.com, alm...@microsoft.com

Specification
https://www.w3.org/TR/css-color-4/#css-system-colors

Summary
The `AccentColor` and `AccentColorText` system colors can be used in CSS to access the system accent color specified on the user's device. This allows developers to apply native app like styling to their web content in contexts where users expect OS theme integration, such as an installed web application.

Blink component
Blink>CSS

Web Feature ID
system-color

Motivation
Without access to system accent colors, developers must hardcode theme values or implement non‑native design patterns, resulting in web applications that visually diverge from user‑configured platform settings. This is especially noticeable in installed web apps, where users expect a level of OS‑level visual integration comparable to native applications.

Initial public proposal
No information provided

TAG review
No architectural changes to make, `AccentColor` and `AccentColorText` are standardized and fully spec'ed CSS keywords.

TAG review status
Not applicable

Risks

Interoperability and Compatibility
This has no interop or compat risks because it is a new CSS system color.

Gecko: Shipped/Shipping (https://bugzilla.mozilla.org/show_bug.cgi?id=1775247)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/136)
There are at least 25 upvotes on the Chromium issue tracking this bug, showing wider interest in the feature.

Ergonomics
`accent-color: auto` also exposes the system accent color via styled form controls. Unlike `AccentColor/AccentColorText`, it was originally unscoped, leading to inconsistent availability of system color styling. We have since aligned behavior by scoping system colors to web app and initial profile contexts, scheduled for Chrome 149. `AccentColor/AccentColorText` is planned for Chrome 150 to allow buffer time in case compat issues with the scoping change need rollback.

Activation
It will not be challenging for developers to take advantage of this feature as-is. This feature would not benefit from polyfills.

Security
This feature could be used for fingerprinting by exposing the user's system accent color to the web. To mitigate this, we've scoped access to the system accent color to only installed web app contexts to narrow the breadth of exposure and additionally made it only accessible to the primary/initial profile to prevent cross-profile fingerprinting scenarios.

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?

No risk.


Debuggability
These new system colors should automatically be picked up by DevTools' styles sidebar for autocomplete/validity.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?
No
`accent-color` does not use the system accent color on Android. With Android automatically sampling system accent colors from the user's wallpaper, there is a security/privacy risk in enabling on Android.

Is this feature fully tested by web-platform-tests?
Yes
While we can't fully test the properties end to end due to the requirement of OS interaction, we have WPTs testing system color validity and automated testing for proper availability scoping. 
Automated browser tests: https://source.chromium.org/chromium/chromium/src/+/main:content/browser/accent_color_browsertest.cc

Flag name on about://flags
CSSSystemAccentColorKeyword

Finch feature name
CSSSystemAccentColorKeyword

Rollout plan
Will ship enabled for all users

Requires code in //chrome?
False

Tracking bug
https://issues.chromium.org/issues/40229450?pli=1

Estimated milestones

Shipping on desktop
150
DevTrial on desktop
115
DevTrial on Android
115

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).

CSSWG issue https://github.com/w3c/csswg-drafts/issues/10372 tracks ongoing discussion regarding privacy mitigations for exposing user‑specific system colors such as `AccentColor` and `AccentColorText`, as no single cross‑UA fingerprinting mitigation approach has yet been standardized. Chromium has implemented context‑based exposure mitigations (e.g. limiting access to installed web app environments) that have undergone internal privacy review and operate within the existing CSS Color specification semantics. While future WG consensus on a unified mitigation model may introduce clarifications around when system color values are exposed, we do not anticipate any API shape changes or other spec resolutions that would introduce meaningful web compatibility or interoperability risk relative to current implementations.

Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5068127364186112?gate=5105472708804608


This intent message was generated by Chrome Platform Status.
Reply all
Reply to author
Forward
0 new messages