Repository navigation
[css-color] [css-ui-4] Authors should have access to accent-color value to use in their code #5900
Description
Edit: Resolved to do this
https://drafts.csswg.org/css-ui-4/#widget-accent
As discussed in today's telcon, there should be a keyword (akin currentColor) or other way to refer to the value of accent-color so that authors can use this in their designs as well.
The advantage of this over a custom property, is decoupling: that libraries can hook into existing code using accent-color (especially given proposed guidance to set it on the root), without the code needing to be aware of the existence of the library.
Activity
bradkemper commentedon Jan 27, 2021
I agree, but I was thinking it should be an environment variable, e.g.
env(accent-color).That could also include a fallback color if the UA didn't have a single accent color to use, e.g.
env(accent-color, blue).Hopefully to do it in a way that doesn't allow using it for fingerprinting.
samuelbradshaw commentedon Jan 27, 2021
I can see the value in both referencing the author-defined accent color on a section of the page, and referencing the user agent's default accent color. Why not both? :)
SebastianZ commentedon Jan 27, 2021
If this should be made available via an environment variable, avoiding fingerprinting is an important point here. Access to
accent-colorprobably needs to be restricted to avoid reading the actual value, otherwise the user agent, operating system or device could be determined when they use a unique color.Though I guess that's something that applies to all environment variables.
Sebastian
LeaVerou commentedon Jan 28, 2021
@SebastianZ This is something set in CSS, so I'm not sure how fingerprinting applies?
SebastianZ commentedon Jan 28, 2021
Well, I assume @bradkemper's suggested environment variable will compute to an actual color value, which will be the color chosen by the user agent by default. So the environment variable needs to compute to the
autovalue or to itself and it needs to be ensured that there's no other way to get the actual color value via CSSOM or other means in order to avoid fingerprinting.Sebastian
frivoal commentedon Apr 26, 2021
I guess it can't be an env variable: such variables are evaluated independently of where you are in the tree, and thus would always return the UA's default accent color, which we cannot share for fingerprinting reasons (see in #6158). If we want the local accent-color, as set by the author, we need something context sensitive, so that wouldn't be an env variable, but something more like the
currentColorkeyword.That said, I wonder if this is really worth the cost, as there's an easy work-around. If an author needs this, they can just as well set their own
--accent-colorcustom property, and use its value to set both the actualaccent-colorproperty and whatever other place they wanted to use that color in.emilio commentedon Apr 26, 2021
So, fwiw. WebKit does expose the OS accent color via
-webkit-focus-ring-color.Gecko has
-moz-accent-colorfor the Firefox UI but we don't expose it to websites. I think I agree with @frivoal that making a more magic keyword for this seems overkill.LeaVerou commentedon Apr 26, 2021
This brings up a more general point: Do we need something like
env()that is context-sensitive?Yes, authors can set
--accent-colorwhen they control the entirety of a website's CSS. But dynamic ways to get values can be very useful when they don't, i.e. for libraries that have to work smoothly with the existing CSS of the host page.I think the fact that UAs are making up their own keywords for this indicates that there's a need for it.
emilio commentedon Apr 26, 2021
Those two keywords are effectively prefixed system colors, not magic CSS values in any other way.
LeaVerou commentedon Oct 19, 2021
Coming back to this, I really think this would be immensely helpful for component authors. Right now every component has its own custom properties for specifying accent color.
I suppose the fingerprinting concerns can be alleviated if reading out
accentColor(or whatever we call it) returns the keyword, and not a resolved color. Is that implementable?If it cannot be read, that does create the problem that it's impossible to use contrasting text over it, but if
color-contrast()is implemented alongside, they can be used together.Though given that
-webkit-focus-ring-coloralready exposes the OS accent color, maybe that ship has sailed?emilio commentedon Oct 19, 2021
@LeaVerou it is implementable, though I don't think it's worth it as similar system settings are exposed in other system colors. Firefox supports a mode that "spoofs" system colors with generic ones and that would also cover these.
Regarding contrast, in Gecko at least we have two keywords:
-moz-accent-colorand-moz-accent-color-foreground(for the foreground color of e.g. the checkmark). I think if we expose one we probably want to expose both (it's generally a good pattern when exposing system colors anyways).LeaVerou commentedon Oct 19, 2021
Oh yeah, that would be great!
emilio commentedon Oct 20, 2021
I think exposing this via system colors makes sense, is trivial for everybody, and should cover most if not all use cases. I don't think a more special keyword is warranted for this.
Maybe
native-accent-color/native-accent-color-foreground(to clarify that it doesn't change depending on theaccent-colorproperty)? OrNativeAccentColorif we want to go with the traditional system-color naming I guess.samuelbradshaw commentedon Oct 20, 2021
Adding a system color like
NativeAccentColorseems like an easy solution, but it doesn't solve the use case of custom third-party components, as mentioned in #5900 (comment). For components, the system-defined accent color isn't what I want if a customaccent-coloris defined. Would it be bad to have a "system color"AccentColorthat provides theaccent-colorif one is defined in the current context, otherwise the defaultaccent-color(which is the system accent color)?EDIT: I guess that would end up being almost exactly like currentColor. So, my opinion is that a new special keyword – a sibling to
currentColor– is warranted. If we followed the same naming convention ascurrentColor, it could be calledaccentColororcurrentAccentColor. As far as I can see, acurrentColor-like keyword would meet all of the use cases defined in this thread.Is it significantly more difficult for a user agent to implement a special keyword, compared to a system color? What downsides are there in a special keyword?
37 remaining items
LeaVerou commentedon Sep 26, 2024
To summarize @frivoal’s concern: WebKit lies about
accentColorbut still uses the correct OS accent color in form controls. You can see this in action in this demo (set your OS default color to something else first): https://result.dabblet.com/gist/d9354b57012bc1f9eaf8edfbc2b39bed/30d00e3ac6eae4dab6e6ac5a05419c62975f5fd3However:
accentColorkeyword, and if anything is reduced by this change.css-meeting-bot commentedon Sep 28, 2024
The CSS Working Group just discussed
[css-color] [css-ui-4] Authors should have access to accent-color value to use in their code, and agreed to the following:RESOLVED: AccentColor takes its value from accent-color, and AccentColorText takes its value from the appropriately contrasting foreground color for AccentColor; these resolve at computed value timeThe full IRC log of that discussion
<emilio> florian: no longer objecting<fantasai> emilio: to restate, this was about making AccentColor and AccentColorText react to accent-color property
<fantasai> emilio: some concern about them resolving at computed value time making it harder to not expose the system color from OS
<fantasai> emilio: but as Florian said, no longer objecting on that basis
<fantasai> emilio: I think general consensus was, make these react to accent-color property
<fantasai> emilio: figure out a reasonable definition for what happens with color/currentColor/accent-color/AccentColor cycles
<fantasai> emilio: That's TBD, can sort out in a separate issue
<fantasai> emilio: I think we were working towards resolving like other system colors at computed value time
<fantasai> emilio: it's easier implementation-wise, and more sense if accent-color changes throughout the tree
<emilio> fantasai: not sure about the resolving about the resolving at computed-value time
<emilio> ... currentcolor doesn't do that
<emilio> ... sympathetic to the impl complexity argument
<fantasai> emilio: I have a counter-example
<fantasai> emilio: all system colors go in pairs, right? Not talking about one keyword, but two
<fantasai> emilio: all system colors that go in pairs resolve early
<fantasai> emilio: changing the color could cause text to be unreadable
<fantasai> emilio: consider you have :root... { background: AccentColor; color: accentColorText; }
<fantasai> emilio: if you change the accent-color further down in the tree, then you can end up with text you can't read
<miriam> q+
<emilio> fantasai: but that's the behavior of color: currentColor and such right?
<emilio> emilio: but color is only one, there's no background / foreground concept
<emilio> fantasai: right, but...
<emilio> miriam: several questions
<fantasai> fantasai: if you set a color that works on a background, and then change it down the tree you can get unreadable text also
<fantasai> fantasai: so don't do that; same thing here.
<emilio> miriam: maybe I wasn't following
<emilio> ... do these get set once at the root and then they stay through the document
<emilio> ... or do they change (both?) when I change accent color
<emilio> fantasai: what emilio is proposing is binding to the element you set them on and then they stay fixed
<Rossen9> ack miriam
<fantasai> s/fixed/fixed as they inherit/
<emilio> ... alternative is to have them as keywords and let them change if accent-color changes
<kbabbitt> q+
<fantasai> s/changes/changes in a descendant/
<emilio> miriam: but then you change accent color and it changes both?
<emilio> fantasai: think we can resolve to do the easier thing (eager resolution) and come back if we hit a use cases that needs it
<fantasai> s/needs it/needs it late/
<fantasai> emilio: I'm fine resolving; but if some concerns with resolving at computed value time then happy to ?
<lea> what about color-scheme and canvas/canvastext?
<emilio> s/?/elaborate
<fantasai> emilio: canvas/CanvasText does eager resolution against color-scheme
<emilio> kbabbitt: little confused because two keywords (accentcolor/accentcolortext)
<emilio> ... the accent-color property influences accentcolor
<miriam> yes, I also have @lea'a question above
<emilio> ... what about accentcolortext
<emilio> ... wouldn't that mess up the contrast
<fantasai> miriam, lea: those resolve at computed value time; emilio is proposing to match them essentially
<fantasai> emilio: same way accent-color affect background of checkbox, but also adjusts tickmark so you can still see it
<fantasai> emilio: you would do same with AccentColorText
<fantasai> emilio: ensures contrast between the two
<miriam> fantasai - the question is about updating them in the document as the color-scheme changes
<fantasai> emilio: you can't specify the exact color of the checkmark, similar with AccentColorText
<fantasai> kbabbitt: what's the intended relationship between these two?
<fantasai> emilio: one is background other is foreground
<fantasai> miriam, the answer to that question is it binds at computed value time
<fantasai> emilio: AccentColor will be what you specify in accent-color
<fantasai> emilio: and AccentColorText will be the foreground color associated with that accent-color
<lea> q?
<lea> q+
<Rossen9> ack kbabbitt
<fantasai> emilio: I don't think there's a precise algorithm, but UAs do have one (that may or may not be fully interoperable but nonetheless ensures contrast)
<emilio> lea: I thought we resolved on when do they resolve?
<emilio> fantasai: didn't resolve on anything
<emilio> lea: what are we discussing?
<emilio> ... my understanding was that the primary objection was florian
<emilio> ... did miriam ask about canvas/canvastext
<emilio> fantasai: yeah
<emilio> lea: is the proposal to do the same for these?
<emilio> fantasai: yeah
<emilio> lea: why not doing that?
<emilio> fantasai: we haven't concluded yet
<emilio> lea: why not?
<Rossen9> ack lea
<fantasai> PROPOSED: AccentColor takes its value from accent-color, and AccentColorText takes its value from the appropriately contrasting foreground color for AccentColor; these resolve at computed value time
<emilio> RESOLVED: AccentColor takes its value from accent-color, and AccentColorText takes its value from the appropriately contrasting foreground color for AccentColor; these resolve at computed value time
clshortfuse commentedon Sep 28, 2024
Thanks for working out the minutiae for this issue.
I believe that the acceptable contrast between AccentColorText and AccentColor is a "courtesy" from the UserAgent but in no means a strict expectation. If a developer wants 3:1, 4.5:1 or even 7:1 it appears as though this information may be computed as needed by the developer.
I'm still assuming AccentColor is a readable value and the matter of fingerprinting has yet to be finalized.
svgeesus commentedon Mar 17, 2025
Trying to implement the resolution and this issue is tagged
css-color-5but that spec has no mention ofAccentColor. It is defined in CSS Color 4 and the accent-color property is defined in CSS Basic UI 4.Which spec is supposed to be changed here? My guess is CSS UI 4.
@LeaVerou @frivoal
LeaVerou commentedon Mar 17, 2025
My guess would be css-color (not a strong opinion though). The concept of
AccentColorpredates theaccent-colorproperty, and one could argue they can be implemented separately. Theaccent-colorproperty is just one of many ways to set it.alisonmaher commentedon Sep 4, 2025
Spec updates added via #12733 (comment)