fix(spec): align w3c-tokens-v2 proposal with DTCG v2025.10 specification - #62
Conversation
Validated all proposal documents against the actual W3C Design Tokens Community Group v2025.10 specification (Format, Color, and Resolver modules). Fixed critical format errors and added missing spec features: - Color $value: hex strings → structured objects (colorSpace, components, alpha, hex) per v2025.10 Color Module - Dimension $value: plain numbers → objects with value+unit per spec - Typography: fontSize as dimension object, lineHeight as number (ratio), fontFamily as string/array format - $extensions key: "exfig" → "com.exfig" (reverse-domain notation) - Modes: hex strings in modes → color objects in $extensions.com.exfig.modes - Added $root, $extends, $deprecated support for tokens-file-source parser - Added non-sRGB color space handling, fontWeight string aliases - Noted Resolver module as alternative to $extensions modes approach - Removed $extensions.exfig.unit (unit is part of dimension $value) - Fixed valid $type list (fontStyle still undocumented in spec) https://claude.ai/code/session_01BwsB119aPMRTX7HrNkxw9C
Summary of ChangesHello @alexey1312, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly updates the design token handling to fully conform with the W3C Design Tokens Community Group v2025.10 specification. The changes introduce structured data types for colors, dimensions, and typography, enhance extension handling, and expand support for advanced token group features. This ensures greater interoperability with other design token tools and improves the robustness of both token export and import processes. Highlights
Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This is an excellent and thorough update to align the design token specification documents with the W3C DTCG v2025.10 standard. The changes are comprehensive and consistent across the design, proposal, spec, and task files. You've clearly paid great attention to the details of the W3C spec, correctly addressing structured color objects, dimension value formats, reverse-domain notation for extensions, and subtle aspects like the lineHeight type and the status of fontStyle. The updated task list provides a clear path for implementation. I have one minor suggestion to further improve the clarity of the design document.
| The dimension `$value` is an object with `value` (number) and `unit` (`"px"` or `"rem"` per spec). Figma variables | ||
| don't carry unit information, so ExFig defaults to `"px"`. The number `$value` is a plain JSON number. | ||
|
|
There was a problem hiding this comment.
While this table correctly maps a standalone LINE_HEIGHT number variable to a dimension token, other parts of the specification (e.g., design-tokens-export/spec.md) state that when decomposing a typography token, its lineHeight property becomes a number token (a unitless ratio). This distinction is subtle and could be a source of confusion for readers of this design document.
To improve clarity, I suggest adding a note here to explicitly state that this mapping applies to standalone number variables, and that lineHeight is treated differently in the context of typography decomposition.
| The dimension `$value` is an object with `value` (number) and `unit` (`"px"` or `"rem"` per spec). Figma variables | |
| don't carry unit information, so ExFig defaults to `"px"`. The number `$value` is a plain JSON number. | |
| The dimension `$value` is an object with `value` (number) and `unit` (`"px"` or `"rem"` per spec). Figma variables | |
| don't carry unit information, so ExFig defaults to `"px"`. The number `$value` is a plain JSON number. | |
| *Note: This mapping applies to standalone Figma number variables. When decomposing a composite `typography` token, its `lineHeight` property is exported as a `$type: "number"` token representing a unitless ratio, per the W3C specification for composite typography values.* |
2 participants
Validated all proposal documents against the actual W3C Design Tokens
Community Group v2025.10 specification (Format, Color, and Resolver
modules). Fixed critical format errors and added missing spec features:
alpha, hex) per v2025.10 Color Module
fontFamily as string/array format
https://claude.ai/code/session_01BwsB119aPMRTX7HrNkxw9C