- From: Chris Lilley via GitHub <sysbot+gh@w3.org>
- Date: Wed, 06 Mar 2024 05:35:14 +0000
- To: public-css-archive@w3.org
svgeesus has just created a new issue for https://github.com/w3c/csswg-drafts: == [css-color] limits to specific color spaces and/or color notations == > I would prefer a normative solution to the problem of handling "extreme" colors produced by `oklab` and `oklch` (e.g, the ones from https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1929679581), which gets us to "some very wide gamut". The value as mentioned in that comment can be expressed in many different ways. https://colorjs.io/apps/convert/?color=oklch(90%25%2090%25%200deg)&precision=4 For example with `hwb(329.3 10.37% -52.94%)` or `lab(83.87 115.6 1.847)`. Implementing gamut mapping only for `oklab`, `oklch` would be highly problematic. I immediately think of these : - `oklch(from lab(83.87 115.6 1.847) l c h)` - `lch(from oklch(90% 90% 0deg) l c h)` - `color-mix(in lch, oklch(90% 90% 0deg), oklch(90% 90% 0deg))` - ... How are these affected when gamut mapping is limited to `oklch` and `oklab` notations? ----- Edit: For me personally it is also a bit a side-track :) I keep stumbling over this because I think it is important. But it isn't directly related to this issue. Discussing limits to specific color spaces and/or color notations should be a separate issue. _Originally posted by @romainmenke in https://github.com/w3c/csswg-drafts/issues/9449#issuecomment-1978878975_ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10035 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 6 March 2024 05:35:16 UTC