- From: Brad Kemper via GitHub <sysbot+gh@w3.org>
- Date: Sat, 03 Oct 2020 05:27:29 +0000
- To: public-css-archive@w3.org
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. -- GitHub Notification of comment by bradkemper Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5544#issuecomment-703049815 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 3 October 2020 05:27:31 UTC