- From: Romain Menke via GitHub <sysbot+gh@w3.org>
- Date: Sun, 20 Mar 2022 09:23:28 +0000
- To: public-design-tokens-log@w3.org
romainmenke has just created a new issue for https://github.com/design-tokens/community-group: == Restrict token ID format == The current format for token id's, naming works great to keep them human readable. Which is generally preferred for GUI's. But it is non-ideal for writing code that consumes design tokens. ```json { "group name": { "token name": { "$value": 1234 } } } ``` This example could be converted to CSS in this way : _Using a BEM like notation to make it valid CSS._ ```css --group-name__token-name: 1234; ``` But this quickly falls apart : ```json { "group name": { "token name": { "$value": 1234 }, "token-name": { "$value": 1235 } } } ``` ```css --group-name__token-name: 1234; /* `-` character now needs to be escaped */ --group-name__token\\-name: 1235; ``` Alternatively it could be a string : ```css order: design-token("group name.token name"); ``` Both examples are problematic. Either significant burden is placed on code authors or on IDE's and tooling creators (possibly on both). Finding a format that works for everything is near impossible. So maybe it needs to be embraced that this is going to be a problem? The spec could formalise that token ID's should not be magically converted to a native variable/property format and only referenced by string. This will make it easier to consume design tokens across multiple contexts without requiring code authors to memorise each conversion. Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/119 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 20 March 2022 09:23:30 UTC