- From: Miriam Suzanne via GitHub <sysbot+gh@w3.org>
- Date: Fri, 26 Jan 2024 00:43:58 +0000
- To: public-css-archive@w3.org
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