Allow specifying the "accent color" of a form control element

[chrishtr]

(not sure which spec this might apply to - css-color-adjust? css-color? css-pseudo?)

Form controls often have a themed highlight color that indicates a "selected" state. For example, in Chromium, we recently changed the look and feel to have a blue highlight color:

(Edge on Mac has similar styling to Chrome but does not use blue). This demo enumerates all of the form controls and can be tested on various browsers.

In addition, some operating systems, such as Mac OS X, allow changing the accent color via a user setting. Safari uses this setting to change the blue color in the screenshots above to a different color.

A number of developers have indicated that they would prefer to be able to change the color. See e.g. this issue. I propose a way to do this via CSS:

• A new css property accent-color that would take on the usual color values. We would specify that a user agent should use this color to change the accent color of a UA-rendered form control, if there is such a well-defined concept for that form control; and otherwise this property has no effect. In the various accessibility and forced color modes, this property is ignored.

In general, form control styling and rendering is not specified, but this particular part of it seems like it can be.

[AmeliaBR]

Is there a reason this can't be done via color alone? Would that currently break the modern OS appearance of the control?

[chrishtr]

Is there a reason this can't be done via color alone? Would that currently break the modern OS appearance of the control?

Two reasons:

• Possibly breaking existing sites
• color doesn't indicate what is being colored. For example, there are non-background strokes like borders or the fill color of a progress input, does color change those?

[fantasai]

Accent color isn't indicating what's being colored, either. I'd say if there isn't a compat restriction, @AmeliaBR's suggestion to re-use color here makes a fair amount of sense unless there's a need to indicate two different colors as input.

FWIW, the CSS UI spec used to say

If 'appearance' is not 'normal', the UA must render the element as if it was the specified user interface (UI) control from the platform. The UA should use the computed values of the 'background-', 'border-', 'padding-', 'outline-', and 'text-decoration' properties when they do not have their initial values and the computed values of 'color', 'font', and 'cursor' (whatever their values) to influence the rendering where possible. Any values from those properties that cannot be used to influence the rendering of the UI control must not affect the rendering at all. For example, the UA should not draw a second border around a UI control that already has a border. If 'background-color' or 'background-image' have non-initial values and the UA is using their values for influencing the rendering of the UI control, then the UA must ensure that the 'color' property is also used to influence the rendering.

That seems to have gotten lost along the way... //CC @tantek

[chrishtr]

Accent color isn't indicating what's being colored, either.

I think it is. It's more specific than color. Also, this is the terminology used in the settings app on Mac OS.

That seems to have gotten lost along the way... //CC @tantek

I see. We need to find out which commit removed it.

[mfreed7]

Is there a reason this can't be done via color alone? Would that currently break the modern OS appearance of the control?

I think the biggest downside to re-using color in this way is that it is non-specific. It would not allow you to, for example, change the text color to one thing, and the "accent" features to something else. Take, for example, the date picker:

<input type=date style="color: red">

which has a text display of the date, and (on some platforms) a picker icon or arrow. If we tie everything to color, the above <input> would have both red text and a red icon. In contrast, accent-color would be specific to just the "accents", allowing black text with a red picker icon, for example:

<input type=date style="color: black; accent-color: red;">

This would also be compatible with the existing Mac concept of an "Accent color", which affects control elements but not text colors. It would also be safe for web compat, since accent-color is a new CSS property.

[heycam]

I agree that tying this to color doesn't seem right.

A few questions that come to mind that I haven't given much thought to yet:

• On macOS, the system accent color affects how focus rings are rendered. Should accent-color be allowed to influence focus styling?
• Is there any relation to <meta name="theme-color">?
• Existing form control designs may be amenable to some accent colors but not others. For example, the Chrome checkbox design wouldn't work with accent-color: white unless the checkmark color changes in response. Is this anything to worry about, or is it sufficient to have some wording that encourages engines to ensure their designs can adapt to all choices of accent-color?
• Do we need to think about how a future form control styling mechanism would interact with accent-color? What about Web components that implement form controls, and which want to adapt their styling to the accent color?

[henke37]

An alternative would be to use pseudo elements to target the classic color property to specific parts of the form control. Naturally, this is not as generic as an accent color, but at the same time allows for detailed control of the color for individual parts.

This is not a mutually exclusive alternative, but interaction between the two would need to be clarified.

[chrishtr]

• On macOS, the system accent color affects how focus rings are rendered. Should accent-color be allowed to influence focus styling?

Focus rings can already be styled with CSS like :focus { outline: 5px solid orange }.

• Is there any relation to <meta name="theme-color">?

For some sites, yes, but I can also see them also wanting to choose a different color.

• Existing form control designs may be amenable to some accent colors but not others. For example, the Chrome checkbox design wouldn't work with accent-color: white unless the checkmark color changes in response. Is this anything to worry about, or is it sufficient to have some wording that encourages engines to ensure their designs can adapt to all choices of accent-color?

I think we should add the language you suggested.

• Do we need to think about how a future form control styling mechanism would interact with accent-color? What about Web components that implement form controls, and which want to adapt their styling to the accent color?

We could perhaps define a pseudo element on custom form controls that accent-color automatically applies to? That's kind of what the accent-color I am proposing conceptually does.

[henke37]

"A" pseudo element. As in One. That has one name, suitable for any form control? X to doubt. If form controls get pseudo elements, there should be as many as that form element needs. Not some generic one size fits all one.

One pseudo class that applies to the correct pseudo elements could work tho.

[othermaciej]

What's the intended scope of accent-color? Is it just color of the checked state of radio buttons and checkboxes? If so, then the name seems inappropriately broad. If it's more things than that, then that may shed light on the name, and whether it should all be one property.

[chrishtr]

Is it just color of the checked state of radio buttons and checkboxes?

Yes, something like that (or similar accents in other form elements).

[henke37]

"Something like that" and "or similar accents" are not phrases that belong in a standard. We need a clear definition of what "accent" means here, not vague hand waving.

[jensimmons]

How does this idea fit into the work of the Open UI project? @gregwhitworth ?