- From: Christopher Cameron via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Feb 2024 13:31:19 +0000
- To: public-css-archive@w3.org
> > "we want to enable content authors to specify colors that no commercially available display can produce, and colors that are physically impossible" > > Creating a gradient or an animation between two in-gamut colors can easily result in an out-of-gamut color, and an author has no practical way of telling if this is going to happen. From the [earlier comment](https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1929442768) > if the two endpoints that you are mixing are both within in a given gamut, then, because the gamuts are mostly-most-of-the-time convex, the line segment between them will still be in the gamut For completeness, the only way one can land a non-trivial way from the gamut would be to do a hue-based gradient at extreme saturation, and even that wouldn't stray all too far, since the gamuts are aren't too far from being conical in `oklab` space. > The only way to prevent this is to force interpolation into a space where all colors are always in-gamut. I think that's a direction to a robust solution to all of the problems here! If we were to bake gamut mapping (to, say, `rec2020`) into the definition of `oklab` and `oklch`, then that would make the `oklch(90% 90% 0deg)` problems in this issue go away. True, baking a specific gamut mapping is not forever-future-proof. But it's better to update the spec as needed than to have behavior update itself in unpredictable ways over time (e.g, as a "yes" answer to [Q1 above](https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1936018833) would). -- GitHub Notification of comment by ccameron-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1938685714 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 February 2024 13:31:21 UTC