[community-group] Implicit vs. explicit typing in composite tokens (#199)

ilikescience has just created a new issue for https://github.com/design-tokens/community-group:

== Implicit vs. explicit typing in composite tokens ==
The current format defines composite tokens in this way:

```json
{
  "shadow-token": {
    "$type": "shadow",
    "$value": {
      "color": "#00000088",
      "offsetX": "0.5rem",
      "offsetY": "0.5rem",
      "blur": "1.5rem",
      "spread": "0rem"
    }
  }
}
```

Unlike in a non-composite token, the values aren't explicitly typed. Take, for instance, in the composite token you have this:
```
...
    "offsetX": "0.5rem",
...
```

In another token, you'd write that as:

```json
{
    "horizontal offset": {
        "$type": "dimension",
        "$value": "0.5rem"
    }
}
```
Currently, the spec is written in such a way that the shadow composite token ALWAYS has a `offsetX` key, and that the `offsetX `key ALWAYS has a value of type `dimension`, so a parser should be able to correctly "guess" the type even though it's not explicitly stated.

However, I see a future where this fact gets hard to maintain. Take the typography composite token, for example.

In issue #102, folks have said that the current list of properties is too restrictive. At the same time, I pointed out that in CSS alone there are 57 possible properties that could apply to typography, and proposed a model of a required base set + optional extended set of properties.

In order for implicit typing to work, the has to list out a single unambiguous type for every property that the composite token might have. There's also the possibility that a property might have two allowed types, which causes some additional complexity.

The other option is to _explicitly_ type values of composite tokens:

```json
  "shadow-token": {
    "$type": "shadow",
    "$value": {
      "color": {
        "$type": "color",
        "$value": "#00000088"
      },
      "offsetX": {
        "$type": "dimension",
        "$value": "0.5rem"
      },
      "offsetY": {
        "$type": "dimension",
        "$value": "0.5rem"
      },
      "blur": {
        "$type": "dimension",
        "$value": "1.5rem"
      },
      "spread": {
        "$type": "dimension",
        "$value": "0rem"
      }
    }
  }
}
```

Obviously this is much harder to type. But the benefit is that the spec doesn't have to maintain the list of type mappings, the parser doesn't have to implement that map, and that composite tokens can have "open" definitions which have a small set of required properties but allow for any additional properties on top of that.

This also blurs the lines between a composite type and a group, which is a much bigger topic.

Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/199 using your GitHub account


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

Received on Monday, 12 December 2022 17:08:16 UTC