- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Jun 2024 08:33:01 +0000
- To: public-css-archive@w3.org
> We will regret limiting to rec2020 in the future. Possibly, but if we ever do, it won't be for some time. We expect an opt-out syntax to exist, and if/when it makes sense for authors to opt out far more often than today, we can make it as easy as possible to do so. > All color functions must behave the same with respect to gamut mapping. With color mixing and relative colors you can not assign special behavior to only oklch, oklab, ... I don't understand this. Why couldn't we? > You can't make the argument that it's fine to clip from rec2020 to display and that rec2029 is sufficiently future proof while also arguing that the current spec is future hostile. These two contradict each other. I don't understand; they don't contradict each other. If you start from Rec2020 colors, they still look reasonable when clipped to sRGB or anything in-between; regardless of what screen you *authored* it on, you'll get an okay and reasonably predictable result when you *display* it. If your color starts outside of Rec2020, our proposal says that, absent any opt-out, the color is eagerly gamut-mapped *into* Rec2020, so then, again, everyone sees approximately the same color. The current spec gamut-maps into the display gamut, so a wide-gamut screen that can display colors well outside of rec2020 can receive a *much* different color than what a rec2020 or srgb screen can display. ccameron has given some examples of this; see <https://github.com/w3c/csswg-drafts/issues/10110> for one. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-2162423303 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 June 2024 08:33:02 UTC