- From: Henry Wilkinson via GitHub <sysbot+gh@w3.org>
- Date: Tue, 07 Feb 2023 16:04:06 +0000
- To: public-design-tokens-log@w3.org
> optionally color tokens can include channels + colorSpace Colourspace information is not an option when defining colours. It is a requirement. The value of RGB = 0.5 is unknowable without this information. Is it in sRGB, Display-P3, linearized sRGB? You can make a guess but there is no way of _knowing_ what colour "0.5" represents without a colourspace value being defined. Even with hex codes! > But it also places pressure on tools to support modern formats because the conversion to hex can be lossy. There is no pressure placed on anybody if this spec adopts hex codes in any way. The rounding issues you mention are also only present if colours are defined with a higher bit depth than the tools that use the token are capable of. I consider this a feature and not a bug. - If users require absolute consistency throughout their pipeline they should pick colours as 8-bit values. Those values should be stored as 16-bit floats, and they should work fine with proper reproduction once converted back to 8-bit integers by programs that can't handle anything else. - If users do not care about this and pick values outside of the destination space with 16-bit float percision they will be reasonably transported through their pipeline and converted to the destination space & bit depth with the percision one would expect. In this way the fallback is provided for automatically with the rendering intent set in the destination program be it a design suite or a CSS pre-processor. In both cases the design token spec would provide a robust container for colour information without carving out fallbacks that will likely just become defacto standards — why bother with 16-bit float values and colourspace conversion if all the other design apps just default to 8-bit sRGB hex values anyways right? It's certianly not "idiot proof" but neither is the hex fallback method, and in both cases values outside of the destination space are going to end up with a fundementally different colour as the fallback anyways. Forcing developers to put in the legwork to handle the conversion of colourspaces and bit-depths also has its risks... I believe that providing a spec that pushes the industry forward by encoding colours properly and providing documentation on how to handle this would be the best approach. Providing a recommendation for an 8-bit sRGB compatibility mode in colour pickers might be a good path forward? In terms of adoption, I think any barriers created by this approach are incentivised to be solved by the organizational value that design tokens provide. -- GitHub Notification of comment by Shrinks99 Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/79#issuecomment-1421019483 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 7 February 2023 16:04:08 UTC