- 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