CSS AccentColor and AccentColorText system colors

[lukewarlow]

Request for position on an emerging web specification

• WebKittens who can provide input:

Information about the specification

• Title: CSS Color Module Level 4
• URL: https://www.w3.org/TR/css-color-4/#valdef-system-color-accentcolor
• GitHub repository: https://github.com/w3c/csswg-drafts/tree/main/css-color-4

Design reviews and vendor positions

• TAG Design Review:

Mozilla has shipped to stable release

Bugs tracking this feature

• WebKit Bugzilla: https://bugs.webkit.org/show_bug.cgi?id=241866
• Radar: rdar://96163997

Anything else we need to know

These would add a standard way to access accent color information that's already exposed through prefixed properties such as -webkit-focus-ring-color.

[lukewarlow]

Just realised this is implemented but returns a hardcoded value, so not sure if this issue is relevant.

[o-t-w]

Yea it shipped in 16.4 but doesn’t respect user settings - as shown in this screenshot the background color is blue when I’ve changed my settings to be yellow.

[nt1m]

-webkit-focus-ring-color being exposed is a mistake. AccentColor intentionally spoofs the color to protect against fingerprinting.

[lukewarlow]

Does it make sense to close with a Concerns privacy label?

[o-t-w]

The fact that it isn't dynamic severely limits its usefulness. Chromium and Firefox managed to implement it in a dynamic way. See this Twitter thread: https://twitter.com/svgeesus/status/1644364238268293122?s=20

[lukewarlow]

Its not a technical issue, WebKit has made a conscious choice to incorrectly implement these values. In the name of "fingerprinting" protection. My opinion is just treat it as supported and if WebKit users get a worse UX then so be it. Its not vital that stuff is the right colour really.

Having said that I would agree that it should just be implemented properly.

[emilio]

The fact that it isn't dynamic severely limits its usefulness. Chromium and Firefox managed to implement it in a dynamic way. See this Twitter thread: https://twitter.com/svgeesus/status/1644364238268293122?s=20

There seems to be some confusion in that thread about how visited link colors work. It's not the same situation. What UAs do is lying about :visited state, not magically changing the value of the VisitedText color. If you apply VisitedText to something not visited you'll get purple.

For context, WebKit used to return the system accent color in webkit-focus-ring-color until https://github.com/WebKit/Webkit/commit/04c640bb1dcea7ab1a75bbdc59a891dde2e9c499.

The way of preventing fingerprinting for system colors is just returning a fixed color like WebKit does. Firefox has code for that too, for Tor. Doing something more complex would prevent using these in things like color-mix or so on.

Returning a fixed color is a trade off that the browser can and should be able to make, and I'd rather avoid doing something weirder just for this (and have no idea how that would look like).

[clshortfuse]

• Is there an acceptable level of entropy? Right now there's only one value. Can that be changed to something like 4, 8, or 16, by means of having presets and rounding to the near value?

• Are there any platform decisions (eg: Added to Home Screen) where this could be reversed? I see the code for focus-ring code uses internals.setUseSystemAppearance(true) to enable this and wonder if there any other plans to adopt this. Would there be heuristics?

• If the decision is to mask, would this affect color-mix()? For example, right now I use the HCT color designed by Google to make things look like native Android (aka: Material You colors), but even on Mac devices, trying to stick to as close to native as possible solves a lot of UX issues. But the workflow is getAccentColorViaComputedStyle() => computeHCT() => writeCSS(). I will probably move off HCT and use OKLCH() and drop all JS. If this is just meant to block JS and Canvas, then would Safari be okay with a fully CSS-based OKLCH color implementation? Or do I have to continue worry about anti-fingerprinting?

[annevk]

I think that WebKit implements these values in a way that is allowed by the specification. I guess the request is whether we want to support them in a different manner? I think as @nt1m explained we would not be comfortable with that, but I'm not sure if marking this as "position: oppose" therefore would be reasonable. That might lead to some further misunderstanding.

[clshortfuse]

I guess that depends on interpretation. For example, the spec says:

For systems that do not have a particular system UI concept, the specified value should be mapped to the most closely related system color value that exists

If the system, at no point displays either rgb(26, 169, 255) or rgb(0, 103, 244) (the hardcoded, anti-fingerprint blue values), then it's not following spec.

If the agent isn't able to express the system color, then I rather it doesn't. In other words, I rather detect if the agent is capable of giving me an accent system color and if not, then allow the user to select one. I rather have a grayed out option to use the system color based on CSS.Supports(), than using a fake color that has nothing to do with the system.

---

A mockup:

[lukewarlow]

Yeah I think the above comment sums up my thoughts.

I would much rather it just not be implemented than be implemented and it not actually work.

If WebKit don't believe the benefits outweigh the downsides then that's their choice but I think that should be reflected with an oppose position here and preferably it not being exposed at all.

[annevk]

Given that we seem to reach different conclusions reading the same specification I opted to file https://github.com/w3c/csswg-drafts/issues/9373.

I don't think it's possible however to do as you wish, at this point in time user agents are expected to support system colors and not supporting them would result in websites not working correctly.

[o-t-w]

This resolution makes the AccentColor keyword a fair bit more useful https://github.com/w3c/csswg-drafts/issues/5900#issuecomment-2380321760

[kyerebo]

In Chromium we've resolved to only expose the system set accent color as AccentColor in certain environments, would WebKit be interested in a similar mitigation? Want to also call to attention that spoofing is explicitly allowed in the spec per UA if that's a route that makes sense.

[annevk]

@kyerebo could you elaborate on what "certain environments" means?

Want to also call to attention that spoofing is explicitly allowed in the spec per UA if that's a route that makes sense.

That is what we do today, assuming nothing changed since 2023.

[kyerebo]

In this case, we've gotten review that scoping AccentColor exposure to installed web apps should be sufficient. However, since this would introduce discrepancy between the availability of accent-color: auto (which is unrestricted) and AccentColor, there's ongoing discussion about what the best route forward would be in https://github.com/w3c/csswg-drafts/issues/10372

Assuming that the spoofing you're referring to from 2023 is just returning a hard-coded value for AccentColor/AccentColorText, is that WebKit's official position on AccentColor exposure and system color support? Or is there interest in supporting it to be practically usable?

[annevk]

Bookmarking/installing a website does not convey trust, so making the user more fingerprintable in such a scenario does not seem good.

Ideally we would find a way to make AccentColor work without a hardcoded value, but thus far there is no workable solution.