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

Interesting stuff.

I think we need to ask ourselves what kind of thing we want to define in this community group. Are we aiming to define a file format that simply stores inert design token data in an interoperable way. _Or_ are we trying to create something akin to a scripting language with functions, operators, etc. that tools can execute to dynamically generate (additional) design tokens?

My assumption had been that we're trying to make the former (and thus things like functions would be out of scope - at least for now).

For what it's worth, I think we could lean on tools to fill the gap. I see no reason why a tool can't read in a _source_ design token file, do some kind of manipulations, and then write out a _generated_ design token file (which itself could be fed into further programmes).

Let's imagine we had a source tokens file like `master-tokens.tkns`:
```json
[
  {
    "name": "base-font-size",
    "value": "1rem"
  },
  {
    "name": "font-size-multiplier",
    "value": 1.5
  }
]
```

It wouldn't be hard to make a command-line utility that can read such a file, be told which tokens to use as base font size and multiplier, and what range of sizes to generate, and then spit out a new token file:

```sh
cat master-tokens.tkns | modular-scale --base="base-font-size"\
    --ratio="font-size-multiplier"\
    --start-point=-1\
    --end-point=2\
    --base-name="font-size-"\
    --suffix-start-value=100\
    --suffix-increment=100 > augmented-tokens.tkns
```

Which might create an `augmented-tokens.tkns` as follows:

```json
[
  {
    "name": "base-font-size",
    "value": "1rem"
  },
  {
    "name": "font-size-multiplier",
    "value": 1.5
  },
  {
    "name": "font-size-100",
    "value": "0.6666rem"
  },
  {
    "name": "font-size-200",
    "value": "1rem"
  },
  {
    "name": "font-size-300",
    "value": "1.5rem"
  },
  {
    "name": "font-size-400",
    "value": "2.25rem"
  }
]
```

You can then imagine combining stringing together a number of such utilities to produce a final output. So while the dating being piped between them is in our standardised token format, you might never need to actually save it out to a new token file (unless you want to). For example:

```sh
cat my-tokens.tkns | modular-scale --bla --foo | add-tints --baz -x | add-shades --bar="whatever" | tkns2sass > output.scss
```

Of course command-line utils are only one kind of tool. These could just as well be interactive GUI tools. Or a mix of both.

Imagine a future version of @NateBaldwinDesign's [Leonardo](https://leonardocolor.io/) that can read a token file, pick out all the color tokens* and present them to the user, let them select which of those to use as key colors and then save the generated colors out to a new token file (or alternatively, just add them to your original file).

Note that my imagined examples make no assumptions about how you've organised or named your tokens.

I think just a "basic" format without functions or operators could already be tremendously useful. Tools like my made up examples could easily provide the kind of results previous comments were suggesting.

-----
*) A use-case like my hypothetical Leonardo scenario implies some notion of type in our format. Otherwise a tool has no reliable way of _knowing_ which tokens are, say, colors and which are something else. Furthermore, I'd expect tools that only know how to do something with certain types of tokens, to just ignore any tokens that are of another type (and hopefully to leave them untouched too).

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

Received on Tuesday, 28 January 2020 23:11:54 UTC