[csswg-drafts] [css-color-6] `contrast-color()` MVP in Level 5 (#9166)

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

== [css-color-6] `contrast-color()` MVP in Level 5 ==
In the NYC F2F in 2022, we discussed defining an MVP of `contrast-color()` that would only return `black` or `white` depending on what color text is most readable for the background color passed. I thought we had a resolution on this, but I can’t find it.

This would address the most common use case where authors have a dynamic color (often user selected) and need to display text on it. Currently authors need to know a lot about a11y and color theory to calculate this reliably, and more often than not the result is suboptmal. You can see an example in this very page: 
<img width="166" alt="image" src="https://github.com/w3c/csswg-drafts/assets/175836/22d65159-965f-4e0d-b568-a311bcc18570">

**UAs are *extremely* keen to ship an MVP for this and have been since 2022**, so it's about time we settle on it, without being distracted by the [multitude](https://github.com/w3c/csswg-drafts/issues/7553) of issues for the extended `color-contrast()` syntax. Out of these issues, only these need to be resolved for this MVP, and none of them is really a roadblock:

- Maybe https://github.com/w3c/csswg-drafts/issues/8539 though I’m hard pressed to think of cases where gamut mapping would actually change the result
- Maybe https://github.com/w3c/csswg-drafts/issues/7358 though ignoring opacity might be fine here

Apart from those, we'd need to also decide on the syntax, which should be much simpler to do for this than for the extended case, since the point of this is to reduce the number of knobs authors have to understand and tweak and just do the right thing automagically, in line with the [TAG principle on balancing simplicity and complxity](https://www.w3.org/TR/design-principles/#simplicity).

I would propose just `contrast-color(<color>)` where:
- `<color>` is assumed to be background and the function returns `white` or `black` depending on which one produces the **highest** contrast (choosing `white` if there’s a tie)
- Contrast algorithm is UA dependent (for background, [this](https://colorjs.io/apps/blackwhite/) is the result with various existing algorithms, though UAs have also been doing [their own explorations](https://web.dev/accent-color/#guaranteeing-contrast) when they implemented `accent-color`). Yes, there is a concern that authors might be unhappy with the text color changing from white to black as UAs refine their algorithms, but remember this would only happen in case it *improves* the result. From conversations with Chrome folks, it appears they are happy to go this route (and have been taking a similar approach for other high level properties, e.g. `text-wrap: pretty`), hopefully other implementors share the same sentiment.

Hopefully we can include this MVP in Level 5, since it's not CR yet.

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


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

Received on Sunday, 6 August 2023 13:27:31 UTC