- From: Romain Menke via GitHub <sysbot+gh@w3.org>
- Date: Sat, 17 Aug 2024 07:10:20 +0000
- To: public-design-tokens-log@w3.org
Thank you for this proposal @drwpow! Overall this looks good to me. ------ > Dimensions: no restrictions on what $value.unit can be (author-defined) We can't have unrestricted units. We will end up having these issues: - tools will have conflicting unit definitions, fracturing the ecosystem - tools will squat units that should be in the spec itself, but with a different definition than desired for the specification Instead we should have a fixed set of specified units and allow any other unit as long as it is vendor prefixed. Then there can't be conflicts between tools as those would be different vendors. There also can't be conflicts between tools and future spec expansion. It still leaves plenty of room for custom definitions. Keep in mind that design token files are a carrier format. How a unit is encoded in a file doesn't dictate how it is exposed in a design tool or the final output for developers. Figma can create a custom unit `y` that is exposed to designers as `y` and output to developers as `y` while encoding it as `figma-y` in token files. If a custom, vendor prefixed, unit is popular and gains adoption among other tools it is also a clear signal that it is useful. Such a custom unit should then go through the spec process to standardize it. -- GitHub Notification of comment by romainmenke Please view or discuss this issue at https://github.com/design-tokens/community-group/pull/244#issuecomment-2294724417 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 17 August 2024 07:10:21 UTC