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.

    /> Thediscussion 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
            
<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
            
<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/79339278-0903-4adb-af09-d898b51b350a%40gmail.com.

Reply via email to