DTCG format update on color tokens and support for color spaces.
Hey everyone, for those who aren't aware, I'm supporting the DTCG as an editor for the spec.
I'm collecting feedback on the current state of the proposal for color tokens in the DTCG spec. Early responses are highly appreciated 🚀🚀
This thread holds the context:
💬 Feedback that is valuable
Proposed format in JSON
{
"my-token": {
"$type": "color",
"$value": {
"hex": "#xxxxxx",
"colorSpace": "color-space",
"channels": [0.1, 0.2, 0.3],
"alpha": 0.5
}
}
}Color spaces supported:
srgb | srgb-linear | display-p3 | a98-rgb | prophoto-rgb | rec2020 | lab | oklab | xyz | xyz-d50 | xyz-d65 | hsl | hwb | lch | oklchNext steps (from DTCG team)
Figure out aliasing.
Possibly "hex": "{my-token.hex}", "channels": "{my-token.channels}",
but this doesn’t feel very natural or particularly safe.
8 week-long RFC where we ask tool makers in particular for feedback.
Below a summary of the thread to get you up to speed if you don't have time to read the whole discussion:
Summary of Discussion on Legacy Color Issue (#137)
Overview:
The discussion revolves around the limitations of using hex color formats in design tokens, advocating for more modern and flexible color representations such as LAB, LCH, and OKLAB.
Participants emphasize the need to future-proof the design token specification to accommodate advanced color spaces already supported by some browsers and anticipated to become standard.
Key Points:
Modern Color Support:
Proposal: Standardize on modern color formats (e.g., OKLCH) instead of hex.
Justification: Modern color formats offer better perceptual uniformity and more accurate color representation.
Flexible Color Representation:
Alternative Syntax:
"colorSpace": "sRGB",
"channels": [0.1, 0.1, 0.1],
"alpha": 1.0Advantages:
This format supports various color spaces and offers higher precision compared to hex values.
Backwards Compatibility and Toolchain Adoption:
Concerns: Current toolchains predominantly support sRGB and hex formats.
Suggestion: Include fallbacks to hex while allowing modern formats for future compatibility.
Practical Implementation:
Fallbacks Example:
"colorSpace": "Display-P3",
"channels": [1, 0.5,0],
"alpha": 1,
"fallback": "#FF8800"Tool Compatibility:
Tools can adopt modern formats without the immediate need for full support, ensuring smoother transitions.
Community Insights and Concerns:
Wide Gamut Support: Limiting to hex/sRGB restricts the potential of design systems to leverage advanced color spaces.
Precision and Accuracy: Higher precision formats like floating-point numbers prevent rounding errors common in hex conversions.
Consensus and Next Steps:
Flexibility in Spec: Propose allowing both hex and advanced color formats to coexist in the specification.
Future-Proofing: Emphasize the importance of a forward-compatible spec that adapts to evolving design tools and browser capabilities.
Conclusion:
The discussion highlights the need to move beyond legacy color formats and adopt a more flexible, future-proof approach in the design token specification, balancing current toolchain limitations with the advantages of modern color spaces.
↔ Related topics
🎨 Expand support for color spaces → Jump to post
Log in to comment and vote
Comments6
Mike (Tokens Studio)
Jun 19, 2024
@Onur Orhon replying in new comment for visibility:
The group proposes using the definitions that exist in CSS Color Module 4. Yes, the values depend on the
colorSpace, and they are defined in the spec per-colorspace.So for example,srgbis defined as having 3 components all in[0, 1]range and follow the specific orderingred,green,blueHSL’s defined as following the ordering
hue,saturation,value. Hues are degrees from0–360(not normalized to1), but the other 2 channels are normalized[0, 1]and do allow negative numbers but are clamped to those ranges, etc.i.e. follow the syntax of thecolor()fn in CSS Module 4, with the exception percentages aren’t allowed; they’re normalized to1and represented as a JSON number.Onur Orhon
Jun 20, 2024
This is very helpful @Mike (Tokens Studio) I wasn't aware of CSS Color Module 4 being so strict about normalization. Thanks!
Chris Kerr
Jun 12, 2024
@Mike (Tokens Studio) Love the inclusion of this, especially OKLCH color space.
Some questions/points from me:
Generally, I'd only use the one color space across all colors in a design system, and it might get very laborious to manage these at the token level
These need to align with color modifiers as I don't believe I'd want differing color spaces between the core value and the modifier value
I assume an uplift to Style Dictionary would be needed to support this new structure?
Will there be support for alpha channels, eg HEXA, HSLA, etc?
Mike (Tokens Studio)
Jun 19, 2024
I guess we can automate this on a tool level (default color space) while on the token level we probably would want to be explicit.
Color Modifiers are currently only supported by Tokens Studio and Style Dictionary. So no worries, it will keep working. However I'm not sure if modifiers will find their way into the spec at this point.
Style Dictionary will support this, assuming this will make it into the spec. We're currently reviewing the proposal within the team working on SD as well.
Alpha channels will be supported.
Onur Orhon
Jun 6, 2024
@Mike (Tokens Studio) would the channel array numbers always be decimal, or will they vary in format based on the selected colorSpace (e.g., integers for sRGB, percentages for HSB, etc.)?
Mike (Tokens Studio)
Jun 19, 2024
https://feedback.tokens.studio/p/dtcg-format-update-on-color-tokens-and-support-for-color/comment/66728735a81823130b7b2502