Re: [community-group] [RFC] Format specification (#1)

:wave: Hello everyone. Just getting some thoughts out here for the group to mull over. 

## High-Level Structure
I feel as though adopting or starting from the CSS syntax and looking in to using rules and properties associated with CSS is going to cause a sort "lock-in" and reduce the "platform/tool/language agnostic" ideal of design tokens.

CSS by it's own nature is a web technology. It does not need to serve native applications, and as such does not have considerations for how different native platforms handle their data or declarations. 

Where a language like JSON/YAML/XML is almost purely data storage and key/value pair associations. Using these languages as a point of origin would result in a less restrictive structure and allow for a simpler association between a token's name and it's value.

Using something like YAML you can still get nested groupings/associations:
```yaml
font:
    size:
        small: 8px;
        medium: 16px;
        large: 32px;
    family:
        display: fancy-font;
        body: normal-font;
```
This could result in tokes like `font.size.small` and `font.family.body`

One other consideration I think may be worth mentioning is that unless the CSS Working Group updates the CSS spec, and then browsers adopt it in a timely manner whatever format we choose will have to be compiled into native CSS (same logic for your pre-processor of choice) anyway.

If we're going to have to compile from "token syntax" to "platform syntax" (this could be `swift`, `css`, `js`, etc) I think it makes the most sense to try and make the "token syntax" simple/easy enough to allow for quick and efficient compilation to any/all of the other "platform syntax" languages.  


## Uniqueness
In my experience we typically only define our tokens once, however I could see a world where at a larger org, or for something like a "bootstrap of design tokens" a team may want to take a "master" tokens file and suppliment or modify it with new definitions for existing tokens.

Example:
"Master" token file defines a color palette using basic terms like `primary` and `secondary`
```yaml
color:
    primary: #7F0000;
    secondary: #320000;
```

The tokens fit _most_ of our needs, but my team wants to change the colors. Rather than create new tokens, it would be nice if we could simply override the existing token definitions.
```yaml
color:
    primary: #6666FF;
    secondary: #33337F;
```

In this example the format would need to function similar to `var`, `let`, or the CSS cascade. If I redefine something further down in the file, or in an import after the original it would need to update the value of the key.

```css
@import tokens-master
@import custom-token-definitions

color: $color.primary;
```
This would be expected to output to
```css
color: #6666FF;
```

## Aliasing
I would agree with this being a must-have. If only for the ability to define specific component/state/relational values based on an existing token's value. 

The biggest use case that our team uses this for is for branding and state values. All of our system's colors have generic names, they are then aliased to product specific values based on that product's branding. The same logic applies to states. It makes more sense to define `color.light`, `color.default`, and `color.dark` once, and then alias states to those values rather than have a new definition for each components hover/active/disabled/focus state. 



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

Received on Tuesday, 21 July 2020 16:13:35 UTC