[css-ui] make accent-color: <color>+ a list of alternatives, not complements

[fantasai]

@tabatkins comment https://github.com/w3c/csswg-drafts/issues/5480#issuecomment-682242811 clearly expresses the core principle I think we should be designing this feature around. It also notes that one of the key problems we need to solve is ensuring contrast.

In that light, I'd like to suggest that instead of thinking of the values of accent-color as a set of complementary colors with particular roles (which is hard to define and to understand), let's define them as a set of alternatives which the UA can pick freely from in order to maximize contrast when using the accent color together with either the foreground or background.

Expected author usage would be to pick either a color that contrasts well with both the color and the background to be used with either, or to pick multiple variant colors, typically of the same hue, at least one of which contrasts sufficiently with color and one of which contrasts sufficiently with the background.

Expected UA usage would be to take whatever part of the form control is in the accent color, and retheme it using a color from accent-color, choosing the one that provides the most appropriate contrast against the parts of the form control styled with the foreground and background colors, with a bias towards colors earlier in the list. (The UA would still be allowed to adjust the chosen accent-color brightness or luminance as required to ensure contrast for usability, but should avoid doing so unless necessary.)

I think this would resolve the concern around what to do with checkboxes, for example, where myriad variations on whether the foreground, background, or accent is used for the border/background/checkmark are possible. I think it would also also be easier for an author to understand how to use.

(It would not give absolute control over which part uses which color, but that isn't the design goal: replacing the UA's accent color with the author's accent color while ensuring sufficient contrast for usability is the design goal.)

---

To provide a more specific example, let's say the UA's accent color is blue, and the author wants violet.

For a Chrome-style checkmark, the UA would be expected to use the violet as the background and the background color as the checkmark. If that doesn't provide sufficient contrast, Chrome could either a) switch the checkmark to using the foreground color or b) adjust the violet to be lighter/darker, whichever the Chrome team feels is a better strategy for its own design goals.

For a MacOS Aqua-style checkmark, the UA would be expected to use the foreground color as the checkmark (as per usual), and violet as the background in place of the Aqua blue. Safari can't switch the checkmark to the foreground color because it overflows the box and overlaps the background around it, so if the violet doesn't provide sufficient contrast it would have to adjust the violet hue before generating the Aqua gradient from it.

Lets say the author wanted a bit more control over the exact shade of violet used. Their first preference is an intense violet matching the luminance of Chrome's blue and similar to Aqua's option selection color; but they recognize that an aqua checkmark will need a lighter color. They specify accent-color: intenseviolet paleviolet. Chrome would see that intenseviolet has the right contrast with the background color and use that; meanwhile Safari on MacOS Aqua would see that while intenseviolet is too dark, paleviolet has enough contrast, and use that color instead of generating its own variation on intenseviolet.

(For a GTK+ hyper-customized theme, the UA might not have any idea what the native controls look like or have any ability to influence it, only to draw it on the screen. In this case an accent-color declaration by itself has no effect. We don't interpret accent-color alone as a color preference stronger than the default preference for matching native controls. But other properties might switch the control into a non-native mode in which it does have an effect.)

[tabatkins]

This doesn't actually solve my problem, which is that an author needs to be able to predict whether their control will be visible on the page, which in general means they need to know what the major/background color will be, so they can ensure it contrasts properly with the ancestor's background.

Knowing that the specified accent-color will definitely contrast with other colors within the control doesn't help with that.

[bradkemper]

Specifying one color as the background doesn't guarantee contrast either, because our don't know how dominant the background is, or if it is contained in a border or has a drop shadow. Suppose the default style of the checkbox was a small transparent box with a black border and a large colored check mark that overflowed the box a lot. Setting a dark, colored background and white foreground would not just destroy the native look, it would make the check mark hard to discern against a white page background, even though that might look fine with some other platform's native checkbox.

My idea was similar to @fantasai's. The author should be able to provide 1-2 dark colors and 1-2 light colors. The UA should treat their own black and white colors as inviolable. If the native control only needs a single dark color to place its white checkbox on, or a single dark color for its checkbox to put on a white box with a black border, then it would pick the first author-provided dark color to use (a darkish violet, let's say). It would be the author's responsibility to pick a dark color that was dark enough to contrast with white or the light colors. Now assume a different UA had more of an Aqua look, with a gradation from solid color to a very dark solid color (with a stop along the way at another color that still contrasted with white) and a white checkbox. So it chooses the first Author provided color for the main color in the gradient, mixes it with black to make the gradient darker, and throws in the second dark color, if provided. Or maybe it uses one of the light colors provided for the base of the Aqua highlight on the otherwise dark gradient. Thus the author is not changing the overall look and feel of the native control, they are just changing the color scheme. And they might create a low contrast mess if their dark colors aren't dark or their light colors are dark, but that is the case with anything the author touches. Authors have the ability to create horrors if they want, but that is the great power that comes with great responsibility.

The issue of a native control not contrasting enough with a page background is no worse here than it is with completely unsettled controls. If authors creates a dark background when not in dark mode, then they get controls that might not contrast well enough with some UAs. But that is a separate problem. Maybe we should have a way to request dark mode controls when not in dark mode. But let's not make that accent-color's problem.

My proposal is accent-colors: <darkest-color> <dark-color> <light-color> <lightest-color>, where the UA only uses what it needs for non-black-nor-white colors (is not required of use more than one in a color interface, but can use up to all four if the control in question starts with enough distinct colors [not just shades or tints of the main color] for it to make sense), and if either of the two middle colors are not provided,it can generate them by mixing black or white with the colors provided. If the author does not order the values from dark to light, well that's on them. Many controls in many UAs would just use one of the colors and would black, white, and shades/tints of that color. The result would be a properly colorized native control.

Any more than this, and the author is not just picking colors for a native control, they are designing something distinctly non-native, where consistency of the control between UAs is more important. There are different techniques to achieve that goal.

[bradkemper]

By keeping native black black and native white white, and keeping gradations to either lighten or darken in a certain direction as they do natively, it forces the author to pick colors that would actually work equally well across all platforms.

This is not meant to be a tool to reverse the contrast of a control or to solve the problem of dark controls on a dark background.

[bradkemper]

In the example used in last week's meeting about Coca-Cola red, if my page background was white, I would provide that red as the darkest color for the control, and a light tint of it as the light color (actually, the author could provide only one color if they chose, and the UA could do a light tint of it by default). If the page background was already Coca-Cola red, then I would probably provide a darker shade of it for the darkest color for the control. So, the guidance for others is that the darkest and lightest colors they provide should be either darker or lighter than the background of whatever is behind them.

I believe the main differences between my concept and @fantasai's are:

• the native control doesn't change most of the places where it is pure black or white

• the author can provide up to four colors, knowing that probably not more than one or two will be used, but where the first ones have to contrast with white, the last ones have to contrast with black, and the first ones have to contrast with the last ones (less so for the middle ones). And the author only ignores that guidance at their own peril.

[fantasai]

This doesn't actually solve my problem, which is that an author needs to be able to predict whether their control will be visible on the page, which in general means they need to know what the major/background color will be, so they can ensure it contrasts properly with the ancestor's background.

You bring this up like it's a killer problem, and yet Chrome's UI team doesn't worry about this problem, despite their color scheme being used for literally every website. It's not a huge problem because the controls are designed using two colors, so they can be visible no matter what the page background. The empty checkbox uses both a border color and a background color, and the filled checkbox uses an accent-color-colored background and a contrasting checkmark. At least one of these colors will contrast with the page background.

Yeah, if the page background is gray (the border color) or, worse, blue (the accent color), it's not great, but it's still visible. Chrome picked that shade of blue knowing that few pages use it as a background. Likewise, an author shouldn't be picking their page background color as their accent color.

Again, if you want to style specific parts of a checkbox, you do that with appearance. If we want an appearance mode that does a little more work for the author and provides specific parts to style, let's do that (separately). But providing accent-color should not switch the browser from "OS-style Form Controls" into "Interop Mode Form Controls" by itself. It should provide a color hint and otherwise let the browser continue to use its normal form control styling.