- 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