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

I agree with @romainmenke and @eeeps here. 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". 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.

I can see some argument that some people use gamut-specific formats because they are aiming to stay inside a particular gamut. But I don't trust that assumption to hold up reliably enough we can build a heuristic around it. Often people use formats because that's the output of a third-party tool, or because someone told them they could access 'more' colors that way.

But mostly I'm skeptical that out-of-gamut colors map neatly into distinct problems, in a way that allows us to address one or the other. Even when you remove non-visible colors, these formats are _designed to not have a gamut_. That's part of the feature. In order for these formats to be perceptually uniform, they need the odd shape. And in order to be future-proof, they need to cover a large range of possible colors. Taken together, that means: 

- Drawing a cone over a large range of oddly-shaped color will always result in some 'empty' space that needs to be filled in. There's not a simple way to exclude _just those non-visible colors_
- 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

If we impose a baked-in limit for (ok)lab/lch formats, I expect:

- 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.
- OR we end up still needing a whole lot of gamut mapping for the colors that are real, but still out-of-gamut on most devices. In which case I'm still skeptical about a 'leave it to operating systems' approach, because that's been the state of color-handling since web-safe colors, and we still just have clipping everywhere.

> For the purpose of this issue it might be best to discuss alternatives in separate issues and link back to them here?
>
> Then this issue can remain focussed on the fact that gamut mapping is an integral part of css-color-4 but hasn't been implemented.

I agree. It seems to me now that the core issue here is not about the specifics of a gamut-mapping algorithm, but a complete objection to the path the CSSWG has taken in colors 4 and 5. If we're going to move forward with any solution, we have to first agree on what problem we're trying to solve.

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


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

Received on Friday, 26 January 2024 00:44:00 UTC