[css-color] [css-ui-4] Authors should have access to accent-color value to use in their code

[LeaVerou]

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.

[bradkemper]

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]

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]

If this should be made available via an environment variable, avoiding fingerprinting is an important point here. Access to accent-color probably 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]

@SebastianZ This is something set in CSS, so I'm not sure how fingerprinting applies?

[SebastianZ]

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 auto value 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]

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 currentColor keyword.

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-color custom property, and use its value to set both the actual accent-color property and whatever other place they wanted to use that color in.

[emilio]

So, fwiw. WebKit does expose the OS accent color via -webkit-focus-ring-color.

Gecko has -moz-accent-color for 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]

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 currentColor keyword.

This brings up a more general point: Do we need something like env() that is context-sensitive?

Yes, authors can set --accent-color when 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.

So, fwiw. WebKit does expose the OS accent color via -webkit-focus-ring-color.

Gecko has -moz-accent-color for 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.

I think the fact that UAs are making up their own keywords for this indicates that there's a need for it.

[emilio]

Those two keywords are effectively prefixed system colors, not magic CSS values in any other way.

[LeaVerou]

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-color already exposes the OS accent color, maybe that ship has sailed?

[emilio]

@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-color and -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]

Regarding contrast, in Gecko at least we have two keywords: -moz-accent-color and -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).

Oh yeah, that would be great!

[emilio]

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 the accent-color property)? Or NativeAccentColor if we want to go with the traditional system-color naming I guess.

[samuelbradshaw]

Adding a system color like NativeAccentColor seems 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 custom accent-color is defined. Would it be bad to have a "system color" AccentColor that provides the accent-color if one is defined in the current context, otherwise the default accent-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 as currentColor, it could be called accentColor or currentAccentColor. As far as I can see, a currentColor-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?

[emilio]

A special keyword means that it needs to be preserved at computed-value time and it generally is more complex, yes, particularly when dealing with interpolation.

Why is custom accent-color special vs. e.g. custom background-color or custom any-other-color? Do we expect it to be as prevalent as currentColor? I honestly doubt so. Components that want to support custom accent colors could do something like var(--accent-color, NativeAccentColor) instead, or what not.

[LeaVerou]

I did mean an accent color that updates according to the accent-color property. I'm not sure just exposing the system color would be that useful.
Using a variable like --accent-color doesn't have the benefits of a common protocol that web components and native components share, it's a convention that the host page needs to know about and use, so it cannot be depended on. Furthermore, it needs to be initialized, whereas accentColor or whatever we call it would always have a reasonable value that fits nicely either with the page (if set by the author) or with the OS UI (if not set by the author).

[samuelbradshaw]

Why is custom accent-color special vs. e.g. custom background-color or custom any-other-color? Do we expect it to be as prevalent as currentColor? I honestly doubt so.

One difference between the current background color and the current accent color is that an accent color is likely to be used in a wider variety of ways – it could be needed as the background, border, text color, text selection color, outline, etc. A background color is not as likely to have as many uses. A background color would likely need be reused as a background color, but inherit could meet that use case.

Components that want to support custom accent colors could do something like var(--accent-color, NativeAccentColor) instead, or what not.

This would work, if the component author could be sure that the page author has defined a custom property --accent-color somewhere in their code. But usually the component author and page author are different people.

[clshortfuse]

The new direction of Google's Material Design (Material You) will use one color to extrapolate a color scheme with multiple palettes. Unfortunately, we would need the RGB value (to get the hue-color-tone). Also, because it's central to the presentation of the page, it would best to be calculated before first paint. That means JS would run in <head>, calculate the palette, and get it all ready for the first paint.

I do worry about fingerprinting because of it though. I guess we can expose a permission? But that doesn't make sense the context of first-paint if the user has to accept. Right now I only care about web apps, so perhaps this value can be auto-granted permission on app install. That's probably a larger conversation though.

• https://github.com/material-foundation/material-color-utilities
• https://material.io/blog/science-of-color-design

[emilio]

Exposing the native accent color came up again in whatwg/html#7993. I think there are two different alternatives:

• Exposing the native accent color as a system color.
• Add a magic keyword a-la-currentColor, which resolves to the resolved accent-color.

I think the fingerprinting concerns can be addressed by UAs the same way we address them for all other system colors (e.g., Firefox uses a fixed blue-ish accent color on Windows).

So, given this, I think I'd propose at least to expose a named system color pair for this. If the need arises in the future, adding a magic keyword can be done on top (though IMO CSS variables would do).

[emilio]

@LeaVerou, let me know if you'd prefer me to open a different issue to expose the "native" accent color using a standard color pair (WebKit/Blink effectively expose them already with the non-standard -webkit-focus-ring-color) and keep this issue for the magic keyword.

I think these are sufficiently related but happy to split that out to a separate issue.

[LeaVerou]

Yes, I think these are separate issues.

[lukewarlow]

I would not want to overload the system keyword for this. I like currentAccentColor (scope creep can we get currentBackgroundColor too 🙏🏻 )

[josepharhar]

Lea mentioned offline that overloading the system keyword is better because of the case where the author doesn't set accent-color to anything. What would currentAccentColor resolve to when accent-color has its default value of "auto"?

[waterplea]

Without this feature accent-color is pretty useless, hopefully it gets added.

[clshortfuse]

Related chromium/chromium@8a73948

With these changes enables the OS-defined accent color on Window to be used by:

• HTML form elements that support CSS property-"accent-color" and set to use default system accent color
• System color keyword - "AccentColor".

Tester - https://codepen.io/shortfuse/pen/LYgoKQe

[LeaVerou]

I would not want to overload the system keyword for this. I like currentAccentColor (scope creep can we get currentBackgroundColor too 🙏🏻 )

Are there any use cases where authors need to access the OS default accent color even if there is an accent-color set? I don't see any, but I could well be missing them. But if there aren't, I don't understand the rationale for this — it complicates the language and the number of keywords authors need to learn with no discernible benefit. Remember theoretical purity is at the bottom of the PoC.

Also, wrt precedent, we update canvas, canvastext etc based on the value of color-scheme, we didn't introduce currentCanvas, currentCanvasText etc keywords.

Agenda+ because it’s 'bout time.

[clshortfuse]

Are there any use cases where authors need to access the OS default accent color even if there is an accent-color set? I don't see any, but I could well be missing them. But if there aren't, I don't understand the rationale for this — it complicates the language and the number of keywords authors need to learn with no discernible benefit. Remember theoretical purity is at the bottom of the PoC.

Personally, accent-color is useless for me. I have no interest in using system controls. I want to use custom elements and styled to match the system's accent's hue. That includes default, hover, active states.

---

Material Design has color schemes completely designed around one user accent color in RGB. From there you extrapolate the rest of the colors. That's the default on Android, and if I want my Web Applications to look native, it starts there.

A live example of what the Web Components look like can be seen here: https://clshortfuse.github.io/materialdesignweb/components/buttons.html with the default based around a single color: #6750A4; the alt is based around #9a4522:

---

For Windows 11 accents on the native controls also use the system color scheme:

If somebody where to want to build an Electron app that looks like native Windows then that color would be important.

---

iOS, iPadOS, Mac OS, tvOS all use variations of the system accent color for controls.

---

Since we are talking Web Components, then you'd have to recreate the native looking controls as Web Components. Personally, I don't want to make one application in JS for Web, one in Kotlin for Android, one in Swift for iOS, and one in .NET for Windows. I use PWAs, which I feel is one of great strengths of Web. I've done the work for Android and ChromeOS (Material Design), and others like (Ionic) have done the legwork for iOS. There are even frameworks like React Native that are built to extend that native feeling all the way to being actually native code on host OS's.

[samuelbradshaw]

I have no interest in using system controls. …
… I want my Web Applications to look native, …

Maybe I'm misunderstanding, but these sound like competing priorities. If you want it to look native, why wouldn't you want to use native system controls?

[clshortfuse]

I have no interest in using system controls. …
… I want my Web Applications to look native, …

Maybe I'm misunderstanding, but these sound like competing priorities. If you want it to look native, why wouldn't you want to use native system controls?

Browsers don't style their controls to match native system controls. Either the native element doesn't exist as a HTML element (tooltip, navdrawer, switch, menu) or their styling is different (button, checkbox, text box, dialog). And I'm rather sure Chrome and Firefox have system-agnostic controls (same on every platform).

That difference is why frameworks like React Native and Ionic exist.

[kizu]

Are there any use cases where authors need to access the OS default accent color even if there is an accent-color set? I don't see any, but I could well be missing them. But if there aren't, I don't understand the rationale for this — it complicates the language and the number of keywords authors need to learn with no discernible benefit. Remember theoretical purity is at the bottom of the PoC.

An additional point: even if there are such use cases, they will be possible by capturing the corresponding colors on the :root with registered custom properties, and accessing them later regardless of if they were overridden. It could be even possible to store both the light & dark versions of them via setting two different color-scheme values on html and body, and storing two sets of custom properties there.

So, I'm for the accent-color following the overridden value, as this will cover the more common use cases and will remove the current confusing behavior, and more complex cases will still be possible, even if a bit hacky.

[css-meeting-bot]

The CSS Working Group just discussed [css-color] [css-ui-4] Authors should have access to accent-color value to use in their code.

The full IRC log of that discussion

<kbabbitt> lea: there's an accent-color property which lets you set the accent color for whole page or subtree
<kbabbitt> ...native ontrols take advantage of it to adapt their display
<kbabbitt> ...even though we have a system color called accentcolor, it returns the os default system color
<kbabbitt> ...seems like an easy win to have it return value of accent-color property
<kbabbitt> ...we have precent for system colors resolving differently based on other properties
<kbabbitt> ... <examples>
<kbabbitt> ... would give web components and components in general ability to adapt in that way same as native components
<astearns> ack lea
<kbabbitt> ... cannot be an environment variable because it's different for subtree
<kbabbitt> fantasai: if we look at the work on base stylesheet for form controls, where tims proposed to use currentcolor and transparent backround
<kbabbitt> ...you often need another color to <missed.
<chrishtr> q+
<kbabbitt> ... author would be able to use accent-color for that
<astearns> ack fantasai
<astearns> ack chrishtr
<kbabbitt> chrishtr: is accent-color inherited?
<kbabbitt> lea: yes
<fantasai> s/<missed/e.g. identify the selected item/
<kbabbitt> chrishtr: so then the color would start out as the same as the text color system color?
<kbabbitt> lea: OS default accent color
<emilio> q+
<kbabbitt> chrishtr: default would be OS default accent color provied by UA, if overrided subtree would receive new value
<kbabbitt> ... would this apply to shadow DOM?
<kbabbitt> lea: I believe inherited properties do
<fantasai> https://www.w3.org/TR/css-ui-4/#widget-accent
<kbabbitt> chrishtr: devlopers can already figure it out?
<astearns> ack emilio
<kbabbitt> emilio: <missed>
<kbabbitt> emilio: you want to make system colors based on the accent color?
<kbabbitt> lea: yes
<kbabbitt> emilio: you would also need text accent color
<kbabbitt> ... we need to deal with cycles
<kbabbitt> ... <missed>
<kbabbitt> ... you set accent-color to the system accent color, now you need to say what happens when this property resolves against the parent
<lea> Proposed resolution: accentcolor and accentcolortext resolve relative to the accent-color property. accent-color: accentColor resolves relative to the parent.
<kbabbitt> ... it's a bit weird with childrens' color schemes
<kbabbitt> ...anyway we need to sort that out, a bit weird you lose system accent color once you override it
<lea> q?
<ntim> What is accentcolortext ?
<kbabbitt> lea: you dont neessarily lose system color, we could define it relative to the parent or resolve realtave to acccent color on the root then you get the os color
<masonf> +1 to this question: what is accentcolortext?
<hober> q+
<ntim> oh I guess it's the text used against an accentcolor background
<masonf> ahh ok. The contrasting color. Thanks.
<kbabbitt> emilio: the accent color system color could be different in @@@ so registered custom property doesn't work as a workaround
<oriol> Wondering about `accent-color: currentcolor; color: accentcolor`
<kbabbitt> fantasai: whit if instead of resolving accent-color: accentcolor against parent, resolve against ???
<kbabbitt> emilio: maybe it's not a big deal because you could set it back to auto
<kbabbitt> fantasai: I don't see a use case for setting accent-color: accentcolor and wanting to change it
<ntim> +1 to oriol's question
<kbabbitt> emilio: once you set accentcolor to something, you can't get it back
<kbabbitt> hober: my initial thought was accentcolortext was a bad name because on sopme [platforms accentcolor s a background som eits a foreground
<kbabbitt> but we could have contrast color accent color
<kbabbitt> s/but/...but
<kbabbitt> fantasai: it would be weird if accent-color property changed with accentcolor
<kbabbitt> lea: accentcolor is defined in css color
<fantasai> ss/
<hober> s/contrast color accent color/contrast-color(accentColor)/
<astearns> s/accentcolor is defined/accentcolortext is defined
<fantasai> https://www.w3.org/TR/css-color-4/#valdef-color-accentcolor
<lea> https://drafts.csswg.org/css-color-4/#valdef-color-accentcolortext
<kbabbitt> emilio: oriol also mentioned this also causes issuse where you have accent-color: currentcolor or accentcolor, you need to define @@@
<hober> q?
<hober> ack
<kbabbitt> fantasai: agree with emilio that this is an editorial that needs to be solved but it's not complicated
<fantasai> s/editorial/issue/
<kbabbitt> astearns: is that where we are?
<emilio> q+
<kbabbitt> fantasai: funtamendal question is: accentcolor system color defined in color-4 references system accent color, will we have a property that allows setting accent-color, instead of being fixed, in same way currentcolor references color property, accentcolor referenes accent-color property
<emilio> ack hober
<florian> q+
<astearns> ack emilio
<fantasai> s/will we/we already/
<kbabbitt> emilio: something you mentioned, system colors right now compute to an actual color
<fantasai> s/instead of being fixed/proposal is instead of being fixed/
<kbabbitt> ...do we want to make accentcolor and accentcolortext keywords that inherit through or just resolve at computed value time?
<kbabbitt> fantasai: I htink you want to give them same treatment as crurrentcolor
<kbabbitt> florian: for privacy reasons I think it's not reasonable to expose it as an actual color
<kbabbitt> emilio: what's the privacy issue?
<astearns> ack florian
<kbabbitt> florian: two parts, one is acceing thjrough tree to value that the author has set
<kbabbitt> ...but if you haven't set anything, accentcolor depends on os settings
<lea> q?
<kbabbitt> ...so there's dobule use case. one is a convenience to the author
<kbabbitt> emilio: it doesn't matter because the keywords resolve in getcomputedstyle anyway
<lea> q+ the part that depends on OS settings doesn't change though
<kbabbitt> florian: two use cases, one is learning or using the os accent color
<kbabbitt> ...one is convenience of figuring out what the accent color you set yourself is
<kbabbitt> ...if we were only talking abou tlatter, it's kind of nice to have it, it could resolve to an actual color, wouldn't be terrible if we didn't
<kbabbitt> ...less convenient to do that but doable\
<kbabbitt> ...if we also want to expose accent color from outside browser, that's a fingerprintingh concern
<kbabbitt> emilio: that concern already exists from not exposing @@@
<kbabbitt> ...OS accent color keyword is shipped in gecko and webkit
<ethanjv> s/abou tlatter/about latter/
<kbabbitt> ...if you wnat to prevent fingerprinting of system colors you cannot expose OS setting
<kbabbitt> ntim: Safari hardcodes accentcolor to blue
<astearns> q+ lea
<kbabbitt> emilio: I don't think we want to inent something complicated
<ethanjv> s/fingerprintingh/fingerprinting/
<kbabbitt> florian: one of the motivating use cases was not at the javascript evel but OS level to know what the OS color is
<emeyer> q?
<ethanjv> s/inent/intent/
<kbabbitt> ...in Safari if you query the color, ti will say blue but will still render as OS color
<kbabbitt> ...bt I think that's the use case that's asked in the ???
<kbabbitt> ...OS uses this color and I want to use it too
<kbabbitt> ...either "no" or yes but I can't discover what it is
<astearns> ack lea
<kbabbitt> lea: we seem to be discussing an issue that's not related to @@@
<kbabbitt> ...whatever browser are already doing, they can cointineu to due
<kbabbitt> ...only change is what happens if accent-color is also provided by author
<kbabbitt> ...what happens when accent-color is not set is orthogonal
<kbabbitt> emilio: if yiu want to make accentcolor a keyword
<ethanjv> s/cointineu to due/continue to do/
<kbabbitt> lea: it already exists
<kbabbitt> emilio: it doesn't resolve aty computed value time
<kbabbitt> lea: doesn't matter when it resolves
<kbabbitt> lea: I wouldn't take ? as a model
<emilio> s/?/currentColor
<matthieud> s/?/CanvasText
<fantasai> s/as a model/as a model so much as CanvasText/
<kbabbitt> emilio: so we are not changing when it is resolved, that's fine with me
<dbaron> (ignore matthieud's substitution when preparing minutes)
<lea> canvas/canvastext and color-scheme seems identical to me: it can be set by the author, but there is also an OS default value that can change
<kbabbitt> ...fantasai seemed to want the currentcolor behavior, that seems not great because if you have matching background and text colors, if you change accentcolor in the tree wihtout settting anything, ?
<kbabbitt> fantasai: we have border color and on one dcouemtn I set to currentcolor, other I set to accentcolor
<kbabbitt> ... or text-emphasis
<astearns> q?
<kbabbitt> emilio: <missed>
<kbabbitt> ...that would change the accent color text but not the background which is odd
<kbabbitt> lea: does this concern apply to canvas and canvastext as well?
<kbabbitt> emilio: that's my point, the reason system colors resolve at computed value time is to prevent this kind of thing where switching color scheme without settingh background would make text unreadable
<kbabbitt> lea: not a new problem
<kbabbitt> emilio: not a problem aty all if we ckeep accentcolor resolving at computed value time
<kbabbitt> lea: why do we need to change it to work like currentcolor?
<emilio> <style>:root { background-color: AccentColor; color: AccentColorText }</style><p style="accent-color: blue">Foo
<kbabbitt> emilio: I don't think we need to but fantasai wanted to
<kbabbitt> fantasai: I don't know if it's required, but ???
<kbabbitt> lea: I agree it's important to make it work with color-mix, but I don't think ???? is needed
<fantasai> s/<missed>/:root { background: AccentColor; color: AccentColorText; accent-color: something } section { accent-color: somethingelse } would change the text color but not the background color
<kbabbitt> emilio: then you actually want it to resolve at computed value time, that's easier
<kbabbitt> ...it works in both cases, I think
<florian> q+
<lea> Proposed resolution: accentcolor and accentcolortext resolve relative to the accent-color property. accent-color: accentColor resolves relative to the parent.
<emilio> Proposed resolution: accentcolor and accentcolortext resolve relative to the accent-color property at computed-value time. accent-color: accentColor resolves relative to the parent.
<ntim> what about `accent-color: currentColor; color: accentColor;` ?
<kbabbitt> florian: unless I'm missing something this won't be usabel
<fantasai> Probably need accentColor to resolve against the parent in both color and accent-color
<kbabbitt> ...it will be usable if the author has actually set an accent-color
<lea> fantasai: why?
<kbabbitt> ...but if they haven't we're giong to default to system accent color which UA is lying about for fingreprinting reasons
<ntim> lea: how do you define the resolution of `accent-color: currentColor; color: accentColor;` ?
<chrishtr> q+
<fantasai> ... yeah that wouldn't work nm
<kbabbitt> ...if you set to orange, it will be orange, if you don't set it will be blue even if it's pink
<astearns> ack florian
<kbabbitt> emilio: unrelated to this resolution
<fantasai> but the see oriol/ntim's question about cycles
<kbabbitt> florian: currently accentcolor does not reflect the property and is used less because browser can and do lie about it
<kbabbitt> ...if we do this, it will be ???
<ntim> q+
<kbabbitt> emklio: browsers lie about system colors all the time
<lea> q+
<kbabbitt> florian: in my view, browsers lie about stste colors all the time and its fine because authors know that, just not use them
<kbabbitt> ...nbut if we make this a combination of a lie and something useful, some of the time it will be useful, sometimes it will be wrong, and it's not good to tempt authors into that
<astearns> ack florian
<astearns> ack chrishtr
<kbabbitt> chrishtr: I think the browser would lie when a developer tries to read back the color but not when painting the screen
<kbabbitt> ...if you use it in CSS it will have the correct system color
<kbabbitt> florian: if we don't resolve at computed value time I would agree, but if we resolve at coputed value time it has become a specific color
<lea> Current behavior: https://result.dabblet.com/gist/d9354b57012bc1f9eaf8edfbc2b39bed/76e4ff46647e8e44936801620ace82ae882d82ee
<kbabbitt> astearns: if it is using the system color at computed value time, it could remain the accentcolor system color
<emilio> q+
<kbabbitt> florain: but we don't have an ?? that tells us what it is we have a lie that tells us it's blue
<ntim> +1 to florian's argument
<kbabbitt> ...if we had kept it as a keyword I think it would work
<kbabbitt> ...but if we resolve to a specific color the lie becomes the truth
<kbabbitt> emilio: if we keep it as a keyword we also need to implement exceptions for canvas, etc
<ntim> If people use AccentColor on their sites, they'll get the hardcoded color unless someone sets accent-color, which is not really useful
<kbabbitt> ...I don't think we want to go that route
<astearns> zakim, close queue
<Zakim> ok, astearns, the speaker queue is closed
<kbabbitt> ...the browser can choose to make system colors ? or not depending on...
<astearns> q?
<kbabbitt> ...in windows high contrast mode, browser will expose actual system colors, those will be useful
<kbabbitt> ...my point is, I don't think we should ? a mitigation strategy here because we already have one
<kbabbitt> ...we can discuss in some other issue, it affects all system colors
<astearns> ack ntim
<emilio> s/?/invent/
<kbabbitt> ntim: florian's point is, if people start using accent color on their site, they could get fingerprinted, unless someone sets accent-color property
<kbabbitt> emilio: browser cannot tell whether syste accent color is red or blue
<kbabbitt> ntim: say you have a ? form control, system color setting is set to red
<kbabbitt> ...another element on page usees accentcolor keyword that element will have hardcoded blue color while native control will have red color
<kbabbitt> emilio: that may be a bug in webkit
<kbabbitt> florian: it's deliberate that it's blue because it protects fingerprinting and authors know that
<kbabbitt> ntim: how does this relate to tab's proposal for custom color schemes?
<kbabbitt> tabatkins: I don't think it has any affect on there; it's slightly realted in that custom color scheems need to be careful about not ? the system color scheme
<kbabbitt> ...other main issues, fingerprinting etc don't seem to apply to custom color scheme
<astearns> ack lea
<kbabbitt> lea: I 've been looking into what happens right now, posted a demo for current behavior
<kbabbitt> ...set system color to pink or something
<kbabbitt> ...regardless of what browsers do, cSS is internally consistent
<kbabbitt> ...you get a live version of what's displayed in accent color
<kbabbitt> ...Firefox and CHrome give you pink, Webkit is lying and gives you blue
<kbabbitt> ...either way it's consistent, mix with white gives you a lighter pink or blue
<kbabbitt> emilio: that was exactly my point
<florian> q+
<astearns> ack emilio
<emilio> ack emilio
<kbabbitt> florian: the reason it wouldn't be useful, yes you get blue and if you mix it you get lighter blue, but actual native controls are pink iN Safari
<emilio> q+
<kbabbitt> ...this is a hint that since some browsers do this on purpose, in genreal using system accentcolor keyword is a bad idea since it will backfire on authors
<kbabbitt> astearns: I'm not hearing consensus, we're not resolving today, we need to take it back to the issue
<astearns> zakim, open queue
<Zakim> ok, astearns, the speaker queue is open
<emilio> FWIW, Firefox lies about the accent color on Windows, but makes the form controls blue too, not the OS accent color
<emilio> Seems WebKit should do that

[nt1m]

This illustrates @frivoal's concerns: https://jsfiddle.net/5mb7efou/

This is rendered like this in WebKit if you've picked the green accent color setting:

This is why florian doesn't think we should generally encourage users to use AccentColor in general.

[fantasai]

@nt1m I think we need to figure this out if we want to have a good default stylesheet for appearance: base form controls, though. There's no way for that stylesheet to use the value of accent-color if we don't have a keyword that references it.

[LeaVerou]

To summarize @frivoal’s concern: WebKit lies about accentColor but 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/30d00e3ac6eae4dab6e6ac5a05419c62975f5fd3

However:

1. This is a problem with the existing accentColor keyword, and if anything is reduced by this change.
2. Even if the OS default were useless, authors having a universal "contract" to communicate accent color to components is still very valuable.
3. I’d argue this is a bug in WebKit and it should instead use the correct color and not expose it if they are so concerned about fingerprinting.

[css-meeting-bot]

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 time

The 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]

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.