Re: [community-group] Loosen up the color type (#79)

Good call out on negative values and values greater than one. This has me rethinking a bit here— mostly the floating point values are a recommendation for RGB colors, as it’s a format that is used but also supports higher color depth than 8 bit channels as we see in browsers (0-255). For RGB, it’s a simple conversion (plus rounding) to get 0-255 equivalent, so it would scale well for folks using RGB. But yes, if defining colors in an opponent color space, negative values are needed and values typically go up to (and above) 100. Cylindrical models would need up to 360 as well, so restricting min/max values for channels is not a great idea.

I’m not familiar with use cases for an encoding value, as an ICC profile name or color space defines that information (with the exception of bit depth in RGB). 

I agree there is some flexibility gains by not clamping values to their colorspace. It also ensures the value is resolved on the consumption side, when rendering context is applied (ie how you want to map back into the color gamut, such as perceptual, relative colorimetric, or absolute colorimetric). 

One point I would question is using negative values in sRGB to specify a color in the P3 gamut… that sounds like a bad practice, but  I don’t know that I would expect the spec to enforce these rules. There are lots of cases where it’s easy to assume the data is wrong, when it’s actually what the user wants. Perhaps at least some degree of flagging in the system to ensure it’s an intended token value rather than a mistake, but still allowing users to keep the value of they want it that way.

-- 
GitHub Notification of comment by NateBaldwinDesign
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/79#issuecomment-1333037351 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 1 December 2022 01:52:00 UTC