- From: Christopher Cameron via GitHub <sysbot+gh@w3.org>
- Date: Thu, 28 Mar 2024 00:43:43 +0000
- To: public-css-archive@w3.org
> @ccameron-chromium I think what you're proposing is > special gamut mapping for `oklch`, a new space to replace it for color-picking-in-code purposes Yes -- either a fix to `oklch` or an alternative that avoids its problems. > and clipping for other color spaces Not quite. I want to ensure color matching, interoperability across browsers, and battery life. Clipping provides this (sort-of), but it isn't great. As we get far out (like, beyond Rec2020), there is a big benefit to preserving hue, and the cost is fairly low. But I wouldn't want to prescribe how to go from P3 to sRGB. > don't we need gamut mapping for all unbounded syntaxes? In Chrome right now, this includes [anything you can write with `color()`](https://codepen.io/eeeps/pen/NWmvLXZ?editors=1100). It's clear to a content author when they are going out of the sRGB gamut in `color(srgb R G B)` syntax because their RGB parameters are no longer in `[0,1]`. The problem with `oklch` is that there is no clear signal that the color is unreasonable or non-existent. -- GitHub Notification of comment by ccameron-chromium Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-2024207960 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 28 March 2024 00:43:44 UTC