Re: [community-group] Prototype composite type in translation tools to ensure it is useful (#126)

Sorry for the delayed response. You raise some valid concerns and I think our spec does perhaps need to be more explicit about expected fallback behaviours for tools that can't or don't want to process composite tokens as a single unit.

For tools that export to code, I had always imagined that an acceptable fallback would be to break up a composite type into individual variables. Using your earlier example:

```json
{
  "type styles": {
    "heading-level-1": {
      "$type": "typography",
      "$value": {
        "fontFamily": "Roboto",
        "fontSize": "42px",
        "fontWeight": "700",
        "letterSpacing": "0.1px",
        "lineHeight": "1.2"
      }
    }
  }
}
```

...and imagining this was being exported to, say, CSS custom properties, then I think this would be an acceptable output:

```css
--type-styles-heading-level-1-font-family: Roboto;
--type-styles-heading-level-1-font-size: 42px;
--type-styles-heading-level-1-font-weight: 700;
--type-styles-heading-level-1-letter-spacing: 0.1px;
--type-styles-heading-level-1-line-height: 1.2;
```

In a way, I guess this is saying that (semantically) a composite token _is_ a typed group (in my mind, they're a bit like interfaces in Typescript - i.e. objects that must have a specific "shape"). As you say, tools that know how to do something special with the group can do that, and other tools are welcome to just use the invidiual sub-values.

So a different CSS export tool (or perhaps just a different configuration?) could produce something like this from the same token:

```css
.type-styles-heading-level-1 {
  font-family: Roboto;
  font-size: 42px;
  font-weight: 700;
  letter-spacing: 0.1px;
  line-height: 1.2;
}
```

Either of those (and maybe other things to) would be reasonable ways to export that token to CSS.

However, I think your proposed typed group syntax is a little problematic. Since tokens without an explicit `$type` inherit from their parent group, all the tokens in your example - except for the "font-family" one - would have a type of "typography". Sure, we could change the rules so that that inheritance behaviour doesn't apply for composite types, but I'd worry that would make the format more difficult for people to understand as it would be more rules to remember.

As I've outlined above, I don't think the current composite type approach prevents tools from "exploding" them into individual tokens / vars / whatever if that's needed for their use-case. The spec explcitly specifies what type each sub-value must be, so a tool can "know" that the `fontFamily` sub-value must have a `fontFamily` value, the `fontSize` sub-value must be a dimension value, and so on. Do you think there is additional info tools wuld need in order to "explode" them out as if they were individual tokens?

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


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

Received on Thursday, 4 August 2022 23:28:31 UTC