*> "Interop risk" means "are other implementers likely to also ship this?". 
>From the positions below, it doesn't seem like there's no risk.*
Thanks for the clarification. Both Gecko and WebKit already implement these 
keywords to some degree today. Gecko exposes the underlying system accent 
color in most contexts, and WebKit currently returns a constant value 
rather than the user’s system color. However, discussion on the WebKit 
position thread indicates interest in a solution that would return the 
actual system accent color. This signals alignment on the capability 
itself, with ongoing discussion primarily focused on mitigating risk rather 
than whether to support it at all.

*> **Are they (Gecko) already shipping the exact same behavior we want to 
ship? *
Not exactly, but there is meaningful implementation overlap. Gecko already 
exposes the underlying system accent color via existing system color 
keywords on most platforms when the relevant pref is true (currently all 
platforms except Windows). `AccentColor/AccentColorText` was enabled 
wherever that infrastructure was already present. While their exposure 
model is a bit looser than what we have, the end result is that Gecko does 
already ship system accent color exposure in supported configurations. 
System color exposure being scoped to installed web apps and initial 
profiles are additional privacy mitigations for us on top of that baseline 
behavior.

*> The discussion on that thread is a bit more subtle than "no signal". Can 
you maybe summarize it here?*
WebKit expressed interest in supporting these keywords in order to better 
align web UI with platform theming, but they also noted that implementation 
would likely depend on identifying an acceptable privacy mitigation for 
exposing user‑specific accent colors, and discussion has focused on how to 
do so safely rather than whether the capability itself is desirable. With 
no consensus being reached yet, currently tracking it as "No Signal". 

On Sunday, April 12, 2026 at 10:48:22 PM UTC-7 [email protected] wrote:

On Fri, Apr 10, 2026 at 11:06 PM 'Alexander Kyereboah' via blink-dev <
[email protected]> wrote:

*Contact emails*
[email protected], [email protected], [email protected], 
[email protected], [email protected]

*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 
<https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22>

*Web Feature ID*
system-color <https://webstatus.dev/features/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.


"Interop risk" means "are other implementers likely to also ship this?". 
>From the positions below, it doesn't seem like there's no risk.
 


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

Are they already shipping the exact same behavior we want to ship? 


*WebKit*: No signal (
https://github.com/WebKit/standards-positions/issues/136)

The discussion on that thread is a bit more subtle than "no signal". Can 
you maybe summarize it here?
 

WebKit Bug: https://bugs.webkit.org/show_bug.cgi?id=241866

*Web developers*: Positive (
https://issues.chromium.org/issues/40229450?pli=1) 
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 
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?*
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. 
WPT: 
https://wpt.fyi/results/css/css-color/parsing/color-valid-system-color.html?label=master&label=experimental&aligned&q=color-valid-system-color.html
 
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 
<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 visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/70fe5ff3-9dd4-4d52-a9a6-8ab663259678n%40chromium.org
 
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/70fe5ff3-9dd4-4d52-a9a6-8ab663259678n%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 visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38f7529d-6fe2-44e2-8e7c-13985c9e0b40n%40chromium.org.

Reply via email to