Re: [community-group] [Format] Token types - optional or required (#63)

Design tokens are always typed, explicitly or implicitly. Style Dictionary for example doesn't care how you type your tokens, but to transform tokens you need to tell it which transforms should apply to which tokens. The built-in transforms implicitly type tokens based on the token object structure, but that is not the only way to do it, you could explicitly add attributes to each token to type them to be targeted by specific transforms.

One thing the format module editors have not tackled fully is separate/multiple files, which would be a necessity for a feature like 'all tokens in this file are of type color'. There were some very initial conversations around having some data inherit from a token group like so:

```json
{
  "brand": {
    "type": "color",
    // type gets applied to all tokens in this token group
    "primary": { "value": "#ff9900" },
    "secondary": { "value": "#00ff00" }
  }
}
```

I would still consider this explicit typing because the user is specifying the types of tokens in the token file. The case for explicit typing in the design tokens spec would be to simplify implementations for library maintainers and tool makers. Without explicit typing, the specification would need to define how libraries and tools should infer design token types based on their value, which can get very complex. We have talked about not enforcing any kind of naming or grouping structure, therefore types could not be inferred based on name or group. 

Another use-case to consider is component tokens. Having a `colors.json` file with all colors makes sense, but if I have a `button.json` tokens file, some sort of typing is required for each token in that file. 

The design token spec should define how tools understand the types of tokens so they can do something meaningful with them. Figma needs to know what a color is versus a padding or border width. In my mind doing this explicitly will lead to less edge cases and potential bugs/discrepancies between tools. However I do see it being more cumbersome than implicit typing, but I would much rather leave that implicit stuff to tool-makers. 

I have an analogy that might help as well. I think of the token spec like the CSS spec. Many people write plain CSS just fine. Some reach to something Sass to improve the authoring experience, but it ultimately compiles to CSS. Libraries like Theo and Style Dictionary would be like Sass. Theo and Style Dictionary could output a valid and explicitly typed design token file from a syntax that infers design token types. Or conceivably Theo and Style Dictionary could understand a design token spec compliant file as well (like how SCSS is a superset of CSS). 

@blackfalcon there is nothing in Style Dictionary that applies attributes to all tokens in a file or in a group, but that could be achieved in a few ways. One would be to use a [custom parser](https://amzn.github.io/style-dictionary/#/parsers) and modify the file's contents as it comes in to Style Dictionary. The other would be to use JS modules as the token source and do that application with a JS function. 


-- 
GitHub Notification of comment by dbanksdesign
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/63#issuecomment-917243401 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 10 September 2021 22:10:44 UTC