Re: [csswg-drafts] [css-color-4] Channel clipping breaks author expectations, especially when using 'perceptually uniform' spaces (#9449)

1. @ccameron-chromium said in https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-2023984610 that he'd be fine with a gamut-mapping rule of the form "minimize the perceptual difference between the specified and displayed color while preserving hue". He's been opposed to mapping algorithms that strictly preserve lightness since he doesn't think he could apply them to images, but he's fine with a better algorithm than clipping if it can also be applied to images.
2. I see a lot of concern in the above discussion about breaking accessibility, specifically measured as WCAG 2 conformance. Now, accessibility doesn't suddenly break when you cross a 4.5 WCAG-2 contrast ratio; it gets gradually worse as contrast decreases, and the WCAG group had to draw a line somewhere. WCAG 3 is probably going to draw a _different_ line with a [different definition of contrast](https://github.com/Myndex/SAPC-APCA/blob/master/documentation/APCA-W3-LaTeX.md).
3. It's hard to figure out an author's intent when presented with a color in isolation. The `oklch(90% 90% 0deg)` in @mirisuzanne's codepen in the OP could have been the result of several different thought processes:
   1. `oklch(from #905 calc(l * 2) calc(c * 2) h)`: making a known color brighter, to the limit of the user's display
   2. `oklch(from #FCC l 90% h)`: making a known color more vibrant, to the limit of the user's display
   3. `oklch(from color(rec2020 0.959 0.047 0.515) 90% c h)`: making a user-chosen color light enough to contrast with `#444`. (unlikely for this particular result color, but I'm not sure how the spec should determine that)
   4. `oklch(from color(rec2020 0.805 0.948 -0.728) l c calc(h-120))`: making a [triadic palette](https://developer.chrome.com/blog/css-relative-color-syntax#triadic_palettes) from a user-chosen color. (even more unlikely for this particular result color, but same difficulties with having the spec figure that out)
4.  Of those thought processes, only (iii) has a specific contrast goal. The others almost certainly have constraints, but the browser can't easily tell what they are. (One could imagine looking for a surrounding [contrast-color()](https://drafts.csswg.org/css-color-6/#colorcontrast) call, but that seems like it'll interact badly with the idea of computed values, and it won't help pages written today.)
5. If we want to be conservative, we could try to ensure the final gamut-mapping algorithm preserves the WCAG contrast the author asked for in (iii). Surprisingly, the author _hasn't_ asked for a specific WCAG score by picking an oklch lightness value. @foolip pointed out to me that none of the WCAG contrast definitions use the same definition of "lightness" as either L\*a\*b* or OkLCH. So I played around with https://jsfiddle.net/mahq9fjL/ and found that for `oklch(90% 90% 0deg)`, for a lightness difference that, for grey, gives a WCAG 2 7:1 contrast ratio, you can vary the chroma and hue and get contrast ratios anywhere from 6:1 to 8:1. For an ACPA score of -90 against grey, varying chroma and hue can find scores from -83 to -101. Constraining to colors in P3, it seems like lightness changes of about 0.03 fall into the hue-caused imprecision in the WCAG scores.
6. If we want to be less conservative, we could mandate that gamut mapping algorithms only change lightness by ∆L, and then authors who want to adjust user-chosen colors into a particular contrast score just need to increase their adjustment by ∆L to be confident it won't be broken by gamut mapping. I don't know what value of ∆L will be acceptable for images, or if it needs to vary depending on the starting lightness level, but the experiments in https://bottosson.github.io/posts/gamutclipping/ seem to indicate that _some_ constraint on the change in lightness can work for images.

-- 
GitHub Notification of comment by jyasskin
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-2035396943 using your GitHub account


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

Received on Wednesday, 3 April 2024 19:15:52 UTC