- From: Namık Özgür Aydın via GitHub <sysbot+gh@w3.org>
- Date: Mon, 16 Sep 2019 22:44:42 +0000
- To: public-design-tokens-log@w3.org
Hi everyone 👋
I would like to share with you how we implemented theme management within our design tool, Toolabs. The theory behind our approach is explained in detail by **Jon Gold** in his article [Declarative Design Tools](https://jon.gold/2016/06/declarative-design-tools/). A simplified version of Toolabs DSM is also available as a [plugin for AdobeXD](https://www.toolabs.com/xdplugin/), you may want to have a look at it to see our theme management in action.
- Regarding naming, as @NateBaldwinDesign mentions some of our concerns in “Definition of Theme” section of his post, we preferred to name it **System States** instead of **Theme**, similar to component states. Although I am not proposing it as name replace, I will keep on using System States in this post because I think it reflects the idea behind our implementation where variations might spread over from color tokens to motion, viewport size to copy language, target platform or for any custom variation such as versioning/branching (although for a limited extent) and any combination of them.
Each combination of state variations is a unique state (e.g, Light Color + Low Elevation + French Language).
- Our implementation of state and token definitions are similar to the example in the post of @mkeftz, where in our case, the order of states is important for preprocessing token values for a given state.
```
{
// define all variant dimensions and possible values
states: [
{
id: "FV5ynCbAL",
name: "media-size",
variations: [
"small",
"medium",
"large"
],
default: "large"
},
{
id: "H5cn-A1b9",
name: "color",
variations: [
"light",
"dark"
],
default: "“light"
},
{
id: "nYdoI4p1O",
name: "contrast",
variations: [
"low",
"high"
],
},
{
id: "be7agXfOD",
name: "language",
variations: [
"English",
"German",
"French"
],
default: "English"
}
],
tokens: [
{
name: 'tokenA',
value: 'baz',
variants: [
{
color: 'dark',
value: 'foo'
},
{
color: 'dark',
contrast: 'high',
value: 'bar'
}
]
}
]
}
```
This definition generates a permutation of **[3 media-size]** x **[2 color theme]** x **[2 contrast]** x **[3 language]** = **36** state variations.
Overrides for token values might be made for any of these variations. However, to process token values for any given state, instead of fallback to the default value on absence of override, our approach is to traverse the array of ordered permutation of variations to find the last override value for that token.
For the given example, the processed value for **tokenA** for state **color_dark + contrast_low** is “**foo**”, not “**baz**”. In order to find this value, we use the permutation of variations for current state to generate the token value matrices :
State Variations | tokenA | ... other tokens
------------ | ------------- | -------------
default | baz | ...
color_dark | **foo** | ...
contrast_low | -- | ...
color_dark + contrast_low | -- | ...
On the other hand, for state **color_dark + contrast_high,** since we already have an override for this exact state, we end up with value "**bar**" :
State Variations | tokenA | ... other tokens
------------ | ------------- | -------------
default | baz | ...
color_dark | foo | ...
contrast_high | -- | ...
color_dark + contrast_high | **bar** | ...
I am aware that a solution like this which depends on permutation of state variations might yield to huge and complex structures and therefore make it less human readable in a file format. Therefore, I am not sure whether this approach is appropriate for design-tokens spec to handle theming or not but wanted to share with you because I believe that when presented with a good UX by design tools, it provides designers a powerful way of managing complex cases beyond just color themes.
--
GitHub Notification of comment by applinist
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/2#issuecomment-531986633 using your GitHub account
Received on Monday, 16 September 2019 22:44:44 UTC