-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Review Request for CSS Color Adjust Level 1 #583
Comments
ExplainersThis specification introduces three new features related to controlling how/when colors are auto-adjusted in certain ways:
The This is necessary to expose as a control, rather than just part of the default behavior of the browser, because the vast majority of pages on the web were authored before color scheme support existed, and thus are generally authored with colors chosen to work well with the (reasonably consistent) set of "default" input/scrollbar/etc colors. Changing this unilaterally on pages has a small but serious chance of rendering these widgets difficult to see or use due to the colors the page is already using. A more common but less destructive issue is that making scrollbars and form controls dark, but keeping the rest of the page in the author-specified colors (usually very light) wouldn't actually achieve anything useful for most pages, and would end up just making pages look awkwardly composed for no benefit to the user. "Forced Colors Mode" is a special accessibility mode exposed by some OSes, most notably Microsoft Windows via its High Contrast Mode feature. This can be thought of as a stronger version of a preferred color scheme: rather than simply preferring a lighter or darker UI, the user is requesting that the OS use only a chosen set of colors. Usually this is used to force a "high contrast" UI (thus the name of the windows feature) for people with impaired vision, but it can be used for a number of other color needs, such as forcing a low contrast color scheme (which helps with some sensory processing issues). Microsoft provided a great explainer for this feature in https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/HighContrast/explainer.md. This color scheme is forced on a webpage regardless of whether it was authored with the expectation of its colors being adjusted. https://drafts.csswg.org/css-color-adjust/#forced-colors-properties defines precisely which properties are affected, and how. The short explanation is that the system color keywords are set to the user's chosen colors, and any property using a color other than those keywords is instead forced into one of the keywords. This can be a fairly destructive process; most pages will still be usable, but it can occasionally cause problems, for which several mitigations are described. The first, whose definition in CSS is deferred to the next level of this spec, is a "backplate" for text, which ensures that text displayed over background images will still be readable. The second is that authors can directly use the system color keywords to style their pages, either unreservedly or gated behind the (prefers-contrast: forced) media query, and have those color choices respected, even if they're different than what the given properties would normally be forced to. The third is the Similar to Forced Colors Mode, user agents sometimes automatically adjust a page's colors to match the user's assumed preference in certain circumstances. For example, use of near-black text over a near-white background is common on the web, but ruinous when printing - printing pure black text is often cheaper and sharper than colored text that is nearly black, and large tracts of background color are expensive to print and sometimes destructive to the paper itself (particular with inkjets). Browsers commonly default to using heuristics to tell when it would be okay to just ignore the author's chosen colors and instead print as black-on-white, which is better for the user. They sometimes provide UI to the user to let them opt into printing exactly what's on the screen, but it's often buried deep in the print UI if it's exposed at all. These heuristics can sometimes misfire, resulting in unreadable text/background combinations. Also, backgrounds and other colors are sometimes very useful to the user even when printing: for example, Google Maps "zebra stripes" the steps of its navigation directions to make it easier to read, alternating between a white and light gray background. The |
As a quick note on time constraints, we are planning to ship the Forced Colors Mode feature in full form in Chromium soon. Given this, we'd appreciate a review of Forced Colors Mode in particular if possible. |
I wanted to follow-up in this thread with a clarification since there was some confusion raised around what is included in the review for Forced Colors Mode, specifically around the various media queries. The main two properties that we were planning on shipping initially are The There was consensus, however, that we would be keeping the |
We discussed this in a breakout today. The We noted that there is an issue in the spec about merging
One thing that I note is that "normal" is more or less synonymous with "light", in practice. Why have two values which mean roughly the same thing? Could "normal" be replaced with "light" as the default? |
Accidentally closed, somehow. |
Hi @fantasai, @tabatkins! Hadley, Lea, and I took another look at this during a breakout this week. Overall we're happy with this set of features that solve a number of real problems. @alice raised a number of points, and we see that the WG has considered each of them. Thanks for bringing this to us! |
HIQaH! QaH! TAG!
I'm requesting a TAG review of CSS Color Adjust Level 1.
This module introduces a model and controls over automatic color adjustment by the user agent to handle user preferences, such as "Dark Mode", contrast adjustment, or specific desired color schemes.
Further details:
You should also know that... we're not thrilled with the very generic name of the
color-adjust
property, but at this point it's been shipping for too long to change. :(We'd prefer the TAG provide feedback as (please delete all but the desired option):
🐛 open issues in our GitHub repo for each point of feedback
The text was updated successfully, but these errors were encountered: