[csswg-drafts] [various] Holistic review/proposal of color-modifying things (#3807)

tabatkins has just created a new issue for https://github.com/w3c/csswg-drafts:

== [various] Holistic review/proposal of color-modifying things ==
@fantasai and I have spent the day reviewing all the various proposals regarding modifying the colors on the page (dark mode, high-contrast, etc), and have come up with an integrated set of proposals that we think address all the use-cases and interact fairly cleanly.

"High-contrast" proposal
========================

```
@media (forced-colors: none | active) {...}

forced-color-adjust: auto | none
```

[Undeprecate some System Colors, and add a few new ones](https://github.com/w3c/csswg-drafts/issues/3804) to match with MS's [High Contrast feature](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HighContrast/explainer.md) (which isn't actually about high contrast, but rather about forcing apps/websites to use a specific, small set of user-chosen colors-- which may or may not be high contrast, and in some cases may specifically be low-contrast).

When forced-color-adjust is `auto` and the user is forcing colors, then the [set of properties defined in the MS proposal](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/HighContrast/explainer.md#css-properties) have their colors overridden to use the system colors defined above. Authors are encouraged to use these system colors for properties that aren't overridden to create a coherent page design when colors are forced.

If the forced background is dark (based on Lab lightness), (prefers-color-scheme: dark) must match; mutatis mutandi for light. This way, websites that support light/dark color schemes will adjust automatically to more closely match the color scheme implied by the forced colors. (This replaces the white-on-black and black-on-white values of the MSFT high-contrast media query proposal.)

The (prefers-contrast) MQ is unrelated and unchanged.

(We might further consider folding 'forced-color-adjust' into the existing 'color-adjust' property somehow, but can discuss whether and how to do that later.)

Light/Dark color scheme proposal
================================

```
@media (prefers-color-scheme: light | dark | no-preference)

color-scheme: only? && [light | dark | <custom-ident>]+

<meta name=color-scheme content="(same values)"> sets initial value of 'color-scheme' on the root.
```

Processing rules as defined by Rune <https://lilles.github.io/specs/supported-color-schemes.html>

If we can change system colors to compute to themselves, then 'color-scheme' changes the used values of the system colors on the element. If not, 'color-scheme' on the root does so for the whole page. In either case, the affected system colors are at least the set defined for "high contrast".

'color-scheme' must also affect input & scrollbar styling.


color-filter proposal
=====================

* [Sydney 2018 discussion minutes](https://lists.w3.org/Archives/Public/www-style/2018Jul/0023.html)
* Issue #2875 for rough proposal

This seems like an early attempt at ability to auto dark-mode a page, but doesn't seem particularly useful now that color-scheme/etc has reasonable consensus.

It might be useful to expose as a quick-and-dirty way for an author to dark-mode their page, but are there use-cases beyond auto-darkmode-ing? If not, maybe just switch this to a keyword property (adding to 'color-adjust'?) that can do "smarter" inversion based on luminance.


inverted-colors proposal
========================

```
@media (inverted-colors: none | inverted)
```

Supported in Safari; it's not clear whether "inverted" means all-pixels inversion, or color-inversion only, or what?

Important to distinguish these, as what authors do in response can vary based on which inversion is performed. (The `img { filter: invert(100%); }` rule in the spec's example, for instance, is only useful for all-pixel inversion; it would be *harmful* for a colors-only inversion.)

So, we either need to *specify* what kind of inversion is allowed to be performed, or add more values capturing the distinctions among the types.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3807 using your GitHub account

Received on Thursday, 4 April 2019 21:17:29 UTC