- From: Philip Jägenstedt via GitHub <sysbot+gh@w3.org>
- Date: Thu, 21 Mar 2024 12:16:22 +0000
- To: public-css-archive@w3.org
My focus here is on the desired behavior of the syntax that has already shipped, and how to get back to an interoperable state ASAP. I understand that chroma reduction is one possible answer to the problem, but I'd like to discuss desired behavior of Oklab/Oklch/Lab/LCH independent of how it's achieved. To visualize the space these gradients are in, here are Oklch hue slices where I've marked the line between `oklab(0 0.15 0.15)` and `oklab(1 0.15 0.15)` with a straight line. It's all outside the sRGB gamut, so the results depend... With channel clipping: ![Oklch slice at hue 45 with channel clipping](https://github.com/w3c/csswg-drafts/assets/498917/8b7c743b-e863-45a2-97ae-68d6932f48eb) With chroma reduction: ![Oklch slice at hue 45 with chrome reduction](https://github.com/w3c/csswg-drafts/assets/498917/2cb3ad1a-0160-4972-9db5-5216b5fe7064) (These are from https://foolip.github.io/okplay/slice/ with editing.) My observations: - There are very visible lines in both cases, so gradients won't be smoothly varying - Channel clipping makes the space more HSV-like and chroma reduction makes it more HSL-like The feedback I've heard from @argyleink is that the HSV-like effect of channel clipping makes it easier to make vibrant gradients, which makes sense since the top right will always be very saturated. It does result in visible hue shifts however. -- GitHub Notification of comment by foolip Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10109#issuecomment-2012127584 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 21 March 2024 12:16:23 UTC