[css-color-6] contrast-color() and gamut mapping

[danburzo]

Some color syntaxes allow out-of-gamut colors that are retained as-is until they're ultimately gamut-mapped for display. Examples include rgb(2 2 2) and color(srgb 2 2 2). Luminance contrast computation should ideally reflect the contrast of the colors being displayed.

To that end, I believe the CIE Y Luminance could be clamped to [0, 1] in the computation of wcag2 contrast, and other contrast keywords / functions.

[LeaVerou]

Not sure this is sufficient. I think we should ensure that the color the calculation is performed on is the same color that is being displayed, so the spec should probably say that the color is gamut mapped first to the output device gamut.

[svgeesus]

I agree with @LeaVerou the luminance of the gamut mapped color should be used, and this can easily be different to merely clamping the luminance of the oog color.

[LeaVerou]

I agree with @LeaVerou the luminance of the gamut mapped color should be used, and this can easily be different to merely clamping the luminance of the oog color.

Does this require CSS to have a function to gamut map a color to the display or can it be done internally in contrast-color()?

[svgeesus]

I wondered about that, the used color is not typically exposed (some fingerprinting risk), so that would be an advantage of a built-in contrast-color() which could know but not expose the used color.

[danburzo]

I wonder: if fingerprinting is a risk of gamut mapping against an arbitrary gamut, wouldn’t the risk be present in any function that uses it under the hood, including contrast-color()? Could I engineer contrast-color() to be as accurate as having direct access to the gamut-mapped color?

Is it a goal of the WICG Color API to ever provide similar gamut-mapping function to the user? If so, should all instances of gamut mapping, (or at least the directly/indirectly accessible functions) work against a list of predefined, approximate gamuts, a la color-gamut media query?

[svgeesus]

Is it a goal of the WICG Color API to ever provide similar gamut-mapping function to the user? If so, should all instances of gamut mapping, (or at least the directly/indirectly accessible functions) work against a list of predefined, approximate gamuts, a la color-gamut media query?

I think that preventing any API that has some slight risk of fingerprinting is an anti pattern and instead the potential drawbacks should be weighed against the potential benefits. We see this in HDR where knowledge of the ambient light level is needed to calculate the HDR headroom but there is a fingerprint worry so ok we can't expose that and in consequence the user can't see the HDR image or video at all because the sun is shining but hey at least we preserved 0.1 bits of fingerprint entropy.

Getting back to the specific question - yes I think Color API should provide that function, which will be way more consistent, simpler and likely more efficient than forcing users to implement it themselves. But such things should be raised and discussed on the Color API repo

[LeaVerou]

What @svgeesus said, plus I think as a general principle, when a decision involves a tradeoff between accessibility and fingerprinting avoidance, we should err on the side of a11y.

To summarize, the proposal we need resolution on is: Before calculating contrast for any color pair, regardless of contrast algorithm, gamut map both colors to the screen gamut.

Side thought: if CSS has access to this operation, I wonder if it may make sense to expose it to authors somehow, e.g. so they could create design systems based on actually displayable accent colors. But that's a topic for another issue.

[svgeesus]

I am fully behind the proposal because the alternative (calculate the contrast with the specified color, even if it is out of gamut of the display or indeed not a visible color at all), makes no sense whatsoever.

[css-meeting-bot]

The CSS Working Group just discussed [css-color-6] contrast-color() and gamut mapping, and agreed to the following:

• RESOLVED: To use the actual displayed color when calculating contrast

The full IRC log of that discussion

<emeyer> chris: We can either say you do contrast between the color you can see and another color, or we say it’s between something that might not be a color and some other color
<emeyer> lea: We need to hear from implementors whether this is possible
<emeyer> chris: I did touch on that in the issue; we don’t expose the used value of a color and don’t need to for this
<emeyer> lea: Not concerned about fingerprinting, I’m concerned about whether all ODes can do this
<emeyer> TabAtkins: They’ll have what they used to present to the monitor
<emeyer> lea: Do colors get gamut-mapped to something they can present?
<Rossen_> q?
<emeyer> TabAtkins: Not sure
<emeyer> lea: We could conditionally resolve, saying we’ll do something if it’s actually implementatble
<chrishtr> hi
<emeyer> chrishtr: What’s the actual proposal here?
<emeyer> chris: To use the actual displayed color when calculating contrast
<TabAtkins> (As much as that information is available.)
<fantasai> +1 to the proposal
<emeyer> chrishtr: So gamut mapping should be taken into account when doing this?
<emeyer> lea: The rationale being otherwise we could get calculation between two non-existent colors
<emeyer> Rossen_: It seems like this makes the most sense
<emeyer> …The question is whether you can get those, and how much work it will take to do so
<fantasai> s/colors/colors. Otherwise you might decide there's enough contrast, but after gamut-mapping there isn't./
<emeyer> …In terms of intended functionality, what Chris is proposing here makes total sense
<emeyer> …If implementors say this is impossible, we should drop the entire thing
<fantasai> +1
<emeyer> chrishtr: I’d like to wait a week to resolve
<emeyer> Rossen_: That objects to what makes sense
<lea> +1
<emeyer> …So let’s resolve on what makes sense, and if it turns out to be impossible, we revisit
<emeyer> RESOLVED: To use the actual displayed color when calculating contrast