In the API owners meeting today we discussed this at some length. There was some concern that the lack of predictability here could cause an adoption barrier for web developers, but also a general agreement that this concern doesn't rise to the level of blocking shipping. From my perspective this is not fundamentally as bad as the unpredictability that comes from font matching / metrics depending on system (and sometimes user) settings.
LGTM1 On Mon, Apr 13, 2026 at 2:16 PM 'Alexander Kyereboah' via blink-dev < [email protected]> wrote: > > *> "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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/38f7529d-6fe2-44e2-8e7c-13985c9e0b40n%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/CAFUtAY_a%2Bw5fqp2KtidgyWcxT23znG%3D2KDV6KEbbXAacHwzu_w%40mail.gmail.com.
