-
Notifications
You must be signed in to change notification settings - Fork 657
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[css-color-4] Need a future-proof way to adjust lightness of a color #10110
Comments
One option for fixing this would be to add more features to gamut mapping, to allow a user to specify a maximum gamut. This is discussed in #10038 Another option would be to expose the To work the above example on
This resulting color is future-proof. It is also using the color space |
How does For example How would In other words how do you give this strong guarantee of "always within gamut" without have surprising differences between css color functions. |
The For that particular color, for the particular operation that I was doing, it works quite well. Performing Over in the page, the computation is just "keep doing what you were doing up to the boundary of the gamut"
For some values that really ramps out quickly. That color I think it would be a good idea to update |
I think I follow what you are saying. I am not sure what the added value is of Is it purely that If so, is then the main concern with the other color notations that it is ambiguous if an author intends to express an sdr color value or an hdr color value when writing |
Okhsl doesn't really scale well past the current targetted space, though Okhsv does handle it a bit better. I guess in its current implementation, you can target other RGB spaces (within reason). For those interested, here are implementations of Okhsl and Ohsv for Display P3 and Rec. 2020. Basically, it is just like Okhsl and Okhsv for sRGB, but you use linear RGB matrices for the targeted RGB gamuts and generate the coefficients using this. This doesn't work for all RGB spaces. IIRC it broke down for ProPhoto. I also didn't bother to create one for A98 RGB, but I think it would work. You can view the calculated coefficients by clicking edit in the linked live preview. This is just for educational purposes and not an endorsement for the idea of CSS using such spaces. Personally, I think these spaces do have limitations and are only rough approximations. They sacrifice some of the perceptual qualities of OkLCh to make essentially color pickers for Oklab and OkLCh, but such utility does have value. |
Yes, I completely agree. And thank you for your visualizations of this on the okhsl issue.
Thanks, that's great work! The best way to solve the problem of "users want to use relative color syntax to adjust lightness of colors, etc" would be to provide those spaces, rather than adding workarounds to try to make |
Related: I’ve been studying designer-crafted color palettes where every color is hand-tweaked by a designer to be aesthetically pleasing, and plotting them to see how they relate to L, C, H coordinates. It’s very early stage but might still be useful. You can find the data & visualizations here: https://palettes.colorjs.io/ |
This issue was going to be discussed at our last face-to-face but we did not get to it, and so it got bumped back to Agenda+. But I’m wondering whether we are actually ready to resolve on something here? If we are, could someone propose a resolution and add Agenda+ again? |
The current relative color syntax offers the promise of being able to adjust properties such as the lightness of a color. When increasing lightness of a color in the
oklch
color space, one very quickly goes far out of the gamut of current displays. This creates a problem wherein the content author is not seeing the color that they specified. In the future, that content will be within the capabilities of display hardware, and the result will not be what the author saw when they created the page.The request in this issue is to create a mechanism wherein authors can avoid this problem.
Worked example:
Suppose I like the color
color(srgb 1 0.09 0.54)
. I may be tempted to create a lighter version of this color by doing:oklch(from color(srgb 1 0.09 0.54) 90% c h)
oklch(65.28% 0.2572 0)
oklch(90% 0.2572 0)
color(srgb 1.37 0.516 0.843)
color(srgb 1 0.785 0.862)
The problem is that this gamut mapped rendition on sRGB displays is not remotely close to the true meaning of the color. By playing some games with the settings of one’s monitor, some displays are capable of producing the true color. On Chrome, because of some quirky implementation details (which are likely to change/be fixed), you can see the true color (for a slightly different example value) here on some displays. The following is a photo of the true color (which doesn’t quite do it justice):
The text was updated successfully, but these errors were encountered: