- From: James Nash via GitHub <sysbot+gh@w3.org>
- Date: Sun, 26 Jun 2022 22:00:35 +0000
- To: public-design-tokens-log@w3.org
If I've understood correctly, your proposal essentially does 2 things:
1. Forces "option" and "alias" tokens to be explicitly partioned within the file
2. Prevents "option" tokens from being exported to code
I'm not sure how useful the 1. part is. Given that the current spec draft already allows both kinds of tokens (if a token's `$value` is a string in the form of `"{path.to.other.token}"` it must be an "alias", otherwise it must be an "option"), asking tools and authors to _additionally_ place tokens into different group-like objects therefore seems redundant. I'm not convinced that makes the files easier to read or understand either.
In fact, I'd argue it makes things more difficult because, at first glance, they look like groups (i.e. JSON objects that have tokens as child objects) but they're not actually groups as they are not part of the path when you reference tokens and they are omitted when generating variable names for CSS output. The current spec draft only has 2 kinds of entities that can exist in token files - groups and tokens. This would introduce a 3rd thing which I feel adds unnecessary complexity.
As per the current spec draft, your example could be rewritten as follows (omitting the descriptions and comments for brevity):
```jsonc
{
"ds": {
"color": {
// "option" in ds.color group
"50": {
"$value": "#ffffff",
"$type": "color"
},
// "alias" in ds.color group
"primary": {
"$value": "{ds.color.50}",
"$type": "color"
},
"group-1": {
// "options" in ds.color.group-1 group
"50": {
"$value": "#000000",
"$type": "color"
},
"150": {
"$value": "#ff0000",
"$type": "color"
},
// "aliases" in ds.color.group-1 group
"primary": {
"$value": "{ds.color.50}",
"$type": "color"
},
"secondary": {
"$value": "{ds.group-1.color.50}",
"$type": "color"
},
"tertiary": {
"$value": "{ds.group-1.color.150}",
"$type": "color"
}
},
"group-2": {
// "option" in ds.color.group-2 group
"50": {
"$value": "#0000ff",
"$type": "color"
},
// "aliases" in ds.color.group-2 group
"primary": {
"$value": "{ds.color.50}",
"$type": "color"
},
"secondary": {
"$value": "{ds.group-2.color.50}",
"$type": "color"
}
}
}
}
}
```
Admittedly this is subjective, but to me that is no more difficult to understand than your proposal. It's also a bit more succinct.
As for the 2nd point - omitting "option" tokens from the output - that's something the current spec draft does _not_ have a solution for. If my above example was exported to CSS, I'd expect the output to be something like this:
```css
:root {
--ds-color-50: #ffffff; /* now also gets output */
--ds-color-primary: #ffffff;
--ds-color-group-1-50: #000000; /* now also gets output */
--ds-color-group-1-150: #ff0000; /* now also gets output */
--ds-color-group-1-primary: #ffffff;
--ds-color-group-1-secondary: #000000;
--ds-color-group-1-tertiary: #ff0000;
--ds-color-group-2-50: #0000ff; /* now also gets output */
--ds-color-group-2-primary: #ffffff;
--ds-color-group-2-secondary: #0000ff;
}
```
However, there are other ways we could prevent some tokens from being exported such as the `$private` proposal being discussed in issue #110. I believe that proposal is preferable to this one as it's more flexible. It could let you exclude _any_ tokens, not just "option" ones. (In fact, some of the ideas folks have proposed in that thread could allow even more ganualarity about where certain tokens can appear or not).
--
GitHub Notification of comment by c1rrus
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/145#issuecomment-1166656970 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 26 June 2022 22:00:36 UTC