Re: [csswg-drafts] [css-ui-3] 'accent-color' spec for checkboxes is incorrect (#5577)

> 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 stiffing 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 https://github.com/w3c/csswg-drafts/issues/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.

-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5577#issuecomment-706817516 using your GitHub account


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

Received on Monday, 12 October 2020 02:16:50 UTC