Re: [w3ctag/design-reviews] Review Request for CSS Color Adjust Level 1 (#583)

Explainers
------------

This specification introduces three new features related to controlling how/when colors are auto-adjusted in certain ways:

* the `color-scheme` property, which controls whether or not browser-provided parts of the page's UI respect the user's chosen color scheme
* the definition of Forced Colors Mode, and the `forced-color-adjust` property which controls whether or not FCM is allowed to apply to a given element
* the `color-adjust` property, which controls whether the browser is allowed to automatically adjust colors to the user's assumed preferences in different media, such as suppressing background colors when printing to save ink

---

`color-scheme` is part of the larger cross-spec definition of Color Scheme support, aka “Dark Mode”. The WebKit team posted a reasonable explainer about the overall feature in <https://webkit.org/blog/8840/dark-mode-support-in-webkit/>. OSes now widely implement the ability to capture and reflect a user's preference for “light” vs “dark” UI, and this information is presented to a web page via the [(prefers-color-scheme) media query](https://drafts.csswg.org/mediaqueries-5/#prefers-color-scheme), allowing a page to choose different colors and images to honor the user's preference. Some parts of the page are styled and rendered by the browser, however, such as form controls and scroll bars, and thus can't be directly restyled by the page author. The 'color-scheme' property negotiates between the uses’s preferred color schemes vs. author-supported / preferred color schemes.

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](https://drafts.csswg.org/css-color/#css-system-colors) 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](https://drafts.csswg.org/mediaqueries-5/#valdef-media-prefers-contrast-forced), 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 [`forced-color-adjust` property](https://drafts.csswg.org/css-color-adjust/#forced-color-adjust-prop), which allows authors to turn off the Forced Colors feature for an element when absolutely necessary (when the chosen colors are meaningful and required for the page to make sense, for example, for color swatches).

---

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 [`color-adjust` property](https://drafts.csswg.org/css-color-adjust/#perf) allows a page to specify that this sort of automatic adjustment should *not* be performed, and instead the exact colors specified by the author should be preserved. [This document](https://wiki.csswg.org/ideas/print-backgrounds) lays out our decision history for the design of this functionality (which later carried over to the `forced-color-adjust` property, which is virtually identical).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/583#issuecomment-740149313