*Contact emails* [email protected] *Explainer* *N/A*
*Specification* https://drafts.csswg.org/css-ui-4/#widget-accent *Summary* Currently, if the *accent-color* property for form controls is set to *auto*, they adopt the system accent color set by the user in their operating system. This happens in all contexts whether on the web or in an installed web application. Current feature state: https://chromestatus.com/feature/6548224737017856 *AccentColor* and *AccentColorText* CSS keywords, which also adopt the system accent color, pose a significant fingerprinting vector if exposed widely on the web. As such, they're currently planned to only be available in installed web app contexts. We want system accent color exposure to match across all vectors, so we should scope *accent-color: auto* to only be available in installed web app contexts as well. This introduces more consistent developer and user expectations for system colors and aligns with fingerprinting restrictions for *AccentColor[Text]*. *Blink component* Blink>CSS <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ECSS%22> *Web Feature ID* accent-color <https://webstatus.dev/features/accent-color> *Motivation* Currently, system accent color features have differing scopes of availability. While *AccentColor[Text]* is planned to only be available in installed web apps, *accent-color: auto* uses system accent color everywhere. This leads to confusing signaling on when developers can expect system accent colors to be available, as well as unintended accessibility and UX side effects as form controls adopt colors on web sites that developers didn't expect. Scoping system accent color availability to installed web apps all up will provide more consistency in this feature intended to allow more native app like styling, while adhering to the fingerprinting restrictions that *AccentColor[Text]* is planned to be subject to (must not be exposed outside of installed web apps). *Initial public proposal* *No information provided* *Search tags* accent-color <https://chromestatus.com/features#tags:accent-color>, accent <https://chromestatus.com/features#tags:accent>, color <https://chromestatus.com/features#tags:color>, system accent color <https://chromestatus.com/features#tags:system%20accent%20color> *TAG review* This is a modification/fix for an existing approved feature. *TAG review status* Not applicable *Risks* *Interoperability and Compatibility* There is potential interoperability risk as WebKit exposes the system accent color completely un-scoped, while Firefox does not. Conversation around fingerprinting mitigation for *AccentColor*, which mentions how it should not have differing availability from accent-color: auto: https://github.com/w3c/csswg-drafts/issues/10372 *Gecko*: Positive ( https://github.com/mozilla/standards-positions/issues/1354) Emilio noted in the attached link that he sees no issues with this. *WebKit*: No signal ( https://github.com/WebKit/standards-positions/issues/613) In discussion. *Web developers*: No signals *Other signals*: *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, but implementing Finch feature flag just in case. *Debuggability* No additional functionality needed to debug this feature. *Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?* No This is scoping an existing feature, which is currently being supported on Windows, Mac, Linux, and ChromeOS. Future support for Android is planned. *Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* No There are no specific tests for this scoping fix. The underlying feature relies on the platform's accent color and necessitates a WebDriver extension to simulate the accent-color property accurately, making it difficult to test. However current WPT coverage for the underlying feature was not broken by this change. WPT tests listed for underlying feature: - https://wpt.fyi/results/css/css-ui/accent-color-parsing.html - https://wpt.fyi/results/css/css-typed-om/the-stylepropertymap/properties/accent-color.html - https://wpt.fyi/results/css/css-ui/animation/accent-color-interpolation.html *Flag name on about://flags* *N/A* *Finch feature name* *WebAppScopeSystemAccentColor* *Rollout plan* Will ship enabled for all users *Requires code in //chrome?* False *Tracking bug* https://issues.chromium.org/issues/481353056 *Estimated milestones* Shipping on desktop 147 *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). The fingerprinting mitigation for AccentColor and AccentColorText do not have widely agreed upon resolution: https://github.com/w3c/csswg-drafts/issues/10372 Depending on the results of that conversation, it's possible we might be able to un-scope this feature in the future. *Link to entry on the Chrome Platform Status* https://chromestatus.com/feature/5106043975761920?gate=4678080817922048 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/01a0f425-0740-4b13-b0f9-a552b2b247a5n%40chromium.org.
