- From: Marc Edwards via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Jul 2022 11:30:04 +0000
- To: public-design-tokens-log@w3.org
>Furthermore, if our format mandates a particular syntax for the value, but how the tool chooses to display or prompt for that value uses an alternate syntax, that's not a problem. I completely agree. > I don't believe "tool makers should improve their internal representation" is a viable option though. In my view, **interoperability is worthless without widespread adoption**. I agree, but it’s a bit tricky with colors. I think your suggestion for conversion and warnings is a good one (“tokens X, Y and Z had out of gamut value and they have been converted to their closest equivalents”). For colors, there’s many scenarios where color values could be altered in an unexpected or destructive way. Maybe a good way to approach the issue is to list all the possible permutations? ## Tool has no color management If the design tool has no color management, there’s really nothing the Design Tokens format can do to help. Raw values will likely be read in with no conversion. They’ll look as incorrect as other colors within the tool. On the positive side, the same color from a token file will likely match a color using the value on the canvas (they’ll both be displayed incorrectly). ## Tool has low color depth If the tool represents colors as 32bit ints, and the source values are floats, rounding will likely occur. Warning is a good strategy. Please note that some tools store individual colors at a higher depth than their actual canvas and renderer. ## Document color space is smaller gamut Even if the tool supports wide gamut colors, the current document may be set to sRGB. In this instance, out of gamut colors may be clipped, resulting in vibrant colors looking duller. For example, a very vivid Display P3 red token being used in a document set to sRGB. ## Document color space is wider gamut If the document color space is wider gamut than the token, conversion and some rounding is likely to occur. This isn’t really an issue when working with floats. ------ Another consideration is that the Design Tokens format proposal, CSS, iOS and other color representations have per-color profiles, but almost all design tools have per-document profiles, if they’re color managed at all. Even in scenarios where everything is behaving, a Design Tokens file with mixed color space colors will almost certainly need _some_ kind of destructive conversion. This is a very long-winded way of saying that I think color space and color depth conversions are likely, and in many cases, unavoidable. The actual format chosen as the representation in the Design Tokens file probably can’t change that. -- GitHub Notification of comment by marcedwards Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/157#issuecomment-1177459523 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 7 July 2022 11:30:06 UTC