[css-ui-4] 'accent-color' spec for checkboxes is incorrect

[tabatkins]

At the moment, the 'accent-color' proposed text for checkboxes says:

A checkbox is typically composed of a "checkmark" glyph on top of a shaded background. The glyph should be considered a "contrasting" accent, while the shaded background behind the glyph should utilize the "primary" accent color.

This implies that Chrome's rendering of a checked checkbox, which is a white check on a blue background, should be doable via the UA stylesheet saying input:checked { accent-color: blue white; }.

However, Chrome currently renders unchecked checkboxes with a white background. This then implies that either:

1. Chrome's UA stylesheet has a more general rule like input { accent-color: white blue; } that applies to the non-checked state, so it continues to use the first color (now white) for its background.
2. Chrome's UA stylesheet has accent-color: blue white; in all cases, but it draws the background of the checkbox using different colors depending on checked state: using the second ("contrasting") color when unchecked, and the first ("primary") color when checked.

If (2) is the case, that's a big problem. All other browsers currently draw checkboxes with a white background in both states, implying that when they adopt 'accent-color', they'll be using the same color in both states. Which color you use for the background is a very important decision, as it is the primary determiner of whether the element is visible against its parent's background or not. This, thus, would fail the "authors can specify colors and have a reasonable idea of how they'll be used" test.

If (1) is the case, that's fine, but it needs to be clarified that Chrome's default behavior is due to this slightly quirky UA stylesheet rule, and if authors just write input { accent-color: white blue; } and nothing else, they will not get things acting like Chrome by default. (Instead, it'll create a checkbox that always has a white background, and has a blue check when checked, matching how other browsers currently render their checkboxes.)

---

[frivoal]

Which color you use for the background is a very important decision, as it is the primary determiner of whether the element is visible against its parent's background or not. This, thus, would fail the "authors can specify colors and have a reasonable idea of how they'll be used" test.

I think you're aiming for a higher bar than I am (and I am not 100% sure where the rest of the WG falls). It think it is important that the controls respond to the provided accent colors:

1. In a way that uses them, because otherwise why bother
2. In a way that works against the colors used in the rest of the page, so that foreground/background/neighboring color contrast is maintained.
3. In a way that can deal with not all components being set up the same on different UAs / platforms.

I think you're focusing on the first 2, and insisting that knowing which color goes in the foreground and which goes in the background is the way to solve that problem. I agree it is a way, but I think that way largely gives up on point 3, and that we should be looking for other ways to solve all 3.

Case in point, Chrome does check boxes differently from other UAs, and by going the way you suggest, we'd be harmonizing that difference away. Yes, that does ensure the accent color is used, and that does also ensure that proper contrast against the background/foreground colors will be maintained, so but it does so by discarding a difference in how the controls work in different browsers. That particular difference is a fairly small thing, but it was intentionally designed that way in the various browsers, and the problem would effectively be the same for more complex controls with more different designs: if you solve the contrast problem by letting the author decide which color goes in which part (in which state), then you require these parts/state combos to exist and be set up the same, which is stifling and not future proof.

To me, wanting all controls to be structured the same is a legitimate need, but it's one that's out of scope for accent-color. I believe accent color can only be a solution to: "I don't care how your control is structured, but please respect by palette somehow". To be usable at all, "somehow" must account for color contrast, preferably in a deterministic way for any given control/palette/environment triplet. But "somehow" cannot tie into which color goes where without defining and locking down the design of the control itself, which in my book is an anti-goal here.

There might be other ways, but I think #5544 or something close to it: you provide a list of colors, and the UA uses the first one of those in which ever part of the control it would normally color, as long as the contrast with whatever is next to it is good enough, and if not, it moves down the list to find a color that does work.

[fantasai]

I believe this issue no longer applies given the current spec. @tabatkins are you OK to close?
https://drafts.csswg.org/css-ui-4/#propdef-accent-color