[csswg-drafts] [css-ui] make accent-color: <color>+ a list of alternatives, not complements (#5544)

fantasai has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-ui] make accent-color: <color>+ a list of alternatives, not complements ==
@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.)

<hr>

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 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.)

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5544 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 23 September 2020 18:01:23 UTC