LGTM3 On Wed, Apr 15, 2026 at 6:15 PM Daniel Bratell <[email protected]> wrote:
> LGTM2 > > /Daniel > On 2026-04-15 17:32, Rick Byers wrote: > > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_a%2Bw5fqp2KtidgyWcxT23znG%3D2KDV6KEbbXAacHwzu_w%40mail.gmail.com?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/CAOmohSKL7eKQjg%2BbHaWv--FNubjUFSP-DqrHJX43ryju0Ets3w%40mail.gmail.com.
