Re: [community-group] Remove JSON derived types from the specification (#120)

I've been making certain assumptions about how tools could / should handle certain scenarios. I'll detail them below for discussion. Whether we accept these or something else, I do agree that these kinds of things should be made explicit in the spec.


### 1. Tools don't necessarily need to use every type of token value. It is acceptable for tools to just ignore types that are not relevant to them

For example, when importing a design tokens file into a colour palette editing tool, I'd argue that it's quite reasonable for that tool to pluck out only the color tokens and present those to its users. Any other type of token could just be ignored. (It might however make sense to require tools that can import and export design token files to at least preserve any tokens they don't use though - see discussion in #157)

Note that for this to work it _is_ necessary for every tool to implement [the type resolution algorithm](https://design-tokens.github.io/community-group/format/#type-0) defined in the spec. However once that has been done (presumably while parsing the imported file), the tool can then choose to operate on whatever subset of tokens are relevant to it.

Therefore, if we retain the basic JSON types like `string`, `boolean`, etc., that doesn't mean tools that have no use for them would be forced to do anything with them.


### 2. The list of types supported by the spec will grow over time

As time goes by, I'm sure new use-cases for design tokens will arise and that is likely to necessitate more types being added to our spec.

I think your CSS `text-align` example has actually highlighted the need for a new type we don't currently have. Perhaps we should add a `textAlignment` type, whose value must be one of `"left"`, `"center"`, `"right"` etc. Just like it does for the other types, the spec would then articulate what the meaning of those values are, so that any tool that wants to work with `textAlignment` tokens can do so in a consistent way.

For example, a translation tool that wants to export them as CSS code could then output the corresponding CSS keywords without quotes.


### 3. The basic JSON types can be useful for extensibility

I'd argue that the`number` type can be useful in the context of UI design & development - e.g. for z-indexes, unitless lineheights, aspect ratios (e.g 16:9 = `1.7777777`), etc.  However, the `string`, `boolean`, `null`, `object` and `array` types probably don't have obvious applications in UI design.

However, used together with `$extensions`, they might enable teams and products to add new, proprietary types. If any of those start to gain traction in the community, they could help inform future versions of the spec where we can add new types to replace them.

The value of `$type` has to be one of the types defined in the spec, so you can't do this:

```jsonc
{
  "token name": {
    "$type": "myFancyType", // <-- not allowed!
    "$value": ...
  }
}
```

However, you _can_ do something like this:

```jsonc
{
  "token name": {
    "$type": "...", // <-- whichever type is the "closest" to what you need
    "$value": ... , // <-- value that is valid for the chosen type
    "$extensions": {
      // Tell your tool to interpret this token's value in a special way
      "com.your-tool.custom-type": "myFancyType"
    }
  }
}
```

Now the "closest" type you pick here could technically be _any_ of the spec's types - one of the more DS-oriented ones like `color`, `duration`, etc. or one the JSON ones `string`, `array`, etc.. However, since our DS-oriented types each have very specific rules for their corresponding values, they probably don't lend themselves to be extended so much. The JSON types on the other hand are semantically meaningless (a bit like `<div>` and `<span>` in HTML), so they probably _are_ useful for this sort of use-case.

While I hope that using extensions & the JSON types in this way to create new, proprietary token types will be relatively rare (I'm certainly not trying to advocate for every tool to go and invent lots of proprietary types!), I do think it's useful to retain this option. As I mentioned earlier, [this may enable "cowpaths" to emerge which future spec iterations can "pave"](https://en.wikipedia.org/wiki/Desire_path). And, [one of the DTCG principles is "Focused, yet extensible"](https://www.designtokens.org/) :-)

-----

If you agree with my assumptions above, then I'd argue we _should_ keep the `number`, `string`, `boolean`, `null`, `object` and `array` types, because:

* We're not forcing tools to have to do anything special with them (because they're allowed to just ignore tokens of that type if they wish), so keeping them shouldn't make life more difficult for tool makers
* They enable teams and tools to create proprietary types, which can help inform future spec iterations and (as per my 2nd point) I do expect more types to be needed in the future


And, aside from all of that, I think we should consider adding something like a `textAlignment` type to the spec!

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


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

Received on Friday, 14 October 2022 22:17:55 UTC