- From: fantasai via GitHub <sysbot+gh@w3.org>
- Date: Wed, 07 Oct 2020 17:14:16 +0000
- To: public-css-archive@w3.org
> 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, to 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 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. -- GitHub Notification of comment by fantasai Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5544#issuecomment-705076588 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 7 October 2020 17:14:18 UTC