- From: Thomas Gossmann via GitHub <sysbot+gh@w3.org>
- Date: Sat, 25 Sep 2021 12:15:35 +0000
- To: public-design-tokens-log@w3.org
Setting _rules_ on groups will mean this: Groups have an impact on tokens within them - or - reading the inverse tokens become dependent on the group they are in. Case A: Groups are only there for _organizing_ tokens, then this shouldn't be allowed as it shouldn't matter in which group a token is in. Case B: Groups become contexts. Means, moving a token from one group to another will change its meaning. Let's make this an example: ```json { "colors": { "type": "color", "example-token": { "value": "#AAA" } }, "dimensions": { "type": "dimension", "example-token": { "value": "#AAA" } } } ``` So, what shall be the algorithm to resolve the value of a token? Possible scenarios for case B: - `colors.example-token` = `#AAA` - `dimensions.example-token` = `2730px` (explanation: 0xAAA = 2730d, pixel is assumed) If groups act as context, then the spec shall deliever a resolving algorithm for how to reach at the value. _I can compare it to_ the heading resolving algorithm for html. The benefit I see is in manually writing groups of tokens all of one type and only defining it once. More chill authoring tokens for sure. I consider this spec to describe the storage of tokens _only_ and would avoid situations where _reading rules_ become necessary. -- GitHub Notification of comment by gossi Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/72#issuecomment-927112856 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 25 September 2021 12:15:37 UTC