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

Let's try to discuss more at the F2F. It's going to be a bit hard to fit things in (there are two almost-conflicting color conferences), but I think there might be an hour on Monday we can do.

> Color level 4 and 5 are build around these tools for generating and adjusting colors on the fly, in a way that relies heavily on gamut mapping to clean up the edge cases.

This specific method of cleaning up edge cases has a lot of effects ([0], [1], [2], [3]), and it took sitting down and trying to implement this to see them. The lesson I take from this is that we needed to have more interaction between implementation and spec in developing these ideas, and that we as implementers should have given stronger feedback earlier in the process.

> I'd add that `color-mix()` and the relative color syntax (which are very popular proposals) also lead to "shipping colors you haven't seen".

With `color-mix()`, if the two endpoints that you are mixing are both within in a given gamut, then, because the gamuts are (mostly) convex, the line segment between them will still be (mostly) in the gamut. So long as the author is specifying endpoints that they can see, then there isn't a risk there (mostly of the time).

Using relative-color syntax to manipulate `oklch` colors will run into exactly these problems, and so I agree that we need to get the spec sorted out before moving forward.

> * Planning for future devices will always result in a wide swath of currently-unsupported colors. There's not a way to design future-proof formats without significant gamut-mapping in the present
> * We end up impacting wider gamut colors that are _not yet_ supported, but are 'real' colors. That's just inventing a new arbitrary gamut, and then we need new formats again every 10 years.

Using the syntax of `color(srgb R G B)`, one can specify any color (at one's own risk), so the ability to specify colors is there, although it might not be the most ergonomic API, and I think that's okay. We can add more ergonomic APIs for new hardware as it comes available.

[0] I worry that this approach of future-proofing will have the opposite effect that it is intending. The current approach encourages content authors today to specify things like the color `oklch(90% 90 0deg)`. They will use that color because they like how it looks on their (probably P3) display.

But in 10 years, that color will likely look extremely different, and the content will not look how the author intended for it to look. Then we'll find ourselves having to fix the problem that existing content looks wrong on new displays, and I suspect that the "fix" will be to retroactively impose something like gamut mapping to P3 to all `oklch` colors.

As an example of how extreme this can be, you can see [this page](https://ccameron-chromium.github.io/webgl-examples/oklab.html) which shows something very close to what `oklch(90% 90 0deg)` really is. (Needs Macbook Pro and Chromium ... and it's a bug so hopefully the bug will be fixed at some point).

I think that a much better approach would be to introduce safe, ergonomic color spaces like [`okhsl`](https://bottosson.github.io/posts/colorpicker/), along with an extension like `okhsl-p3` (and maybe `okhsl-rec2020`). That way, authors can create content knowing "I'm specifying exactly what I'm seeing and nothing more".

[1]  Breaking [color matching with images and canvases](https://github.com/w3c/csswg-drafts/issues/7610#issuecomment-1219057329).
[2] 2D canvas ambiguity. What space should CSS colors be mapped to in 2D canvases, where the target gamut is unknowable? Especially for things like floating-point 2D canvases
[3] Several [numerical and definitional issues](https://github.com/w3c/csswg-drafts/issues/7653#issue-1354160102) with the algorithm.

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


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

Received on Tuesday, 6 February 2024 12:39:48 UTC