Re: [community-group] [Discussion]: How to transform composite tokens (#226)

Does the spec need to have an explicit view on this at all?

In my mind composite tokens are a bit like "styles" in Figma (or equivalents in other design tools). They're a structured set of values that, in design tools, are usually selected and applied as a single unit. I think they still make sense as "design tokens" though, as they're still named design decisions and likely to be part of a design system team's vocabulary.

When it comes to translating them to code, there are several ways they might be represented. On some technology platforms, there might be an analogous "group" construct that lets you apply them all at once, in others there may not. And sometimes both ways might be possible.

The 2 options in the OP demonstrate this exactly. I'd argue which one you choose (why not both?) is up to your team.

The same can be true in other programming languages. For example, the shadow token from the OP in CSS _could_ be expressed as a single CSS var:

```css
:root {
  --shadow-token: 0.5rem 0.5rem 1.5rem 0rem #00000088;
}

/* application */
.foobar {
  box-shadow: var(--shadow-token);
}
```

But it could just as well be "exploded" into its individual sub-values:

```css
:root {
  --shadow-token-offset-x: 0.5rem;
  --shadow-token-offset-y: 0.5rem;
  --shadow-token-blur: 1.5rem;
  --shadow-token-spread: 0rem;
  --shadow-token-color: #00000088;
}

/* application */
.foobar {
  box-shadow:
    var(--shadow-token-offset-x)
    var(--shadow-token-offset-y)
    var(--shadow-token-blur)
    var(--shadow-token-spread)
    var(--shadow-token-color);
}
```

Neither is right or wrong. It just comes down to individual teams' preferences and requirements.

While I'll admit that exploding the parts of the shadow token is something folks are unlikely to do as shadow values in CSS always seem to be applied as a unit, the same isn't necessarily true for something like a border which might be applied all at once as a shorthand value or individually using the long hand properties:

```
.shorthand {
  border: var(--border-token);
}

.longhand {
  border-color: var(--border-token-color);
  border-width: var(--border-token-width);
  border-style: var(--border-token-style);
}
```

Or indeed a typography token which, at least in CSS, would have to be exploded into individual values because there's no shorthand property that covers them all:

```css
:root {
  --typography-token-font-size: 1rem;
  --typography-token-font-family: Comic Sans MS;
  --typography-token-font-weight: bold;
  --typography-token-line-height: 1.4;
  --typography-token-line-height: 1.4;
}

.heading {
  font-size: var(--typography-token-font-size);
  font-family: var(--typography-token-font-family);
  /* and so on */
}
```

For that particular type, you could event export the whole token as a CSS class (or a Sass mixin):

```css
.typography-token {
  font-size: 1rem;
  font-family: Comic Sans MS;
  /* and so on */
}
```

I suppose a DS team might even export grouped and exploded versions to give downstream product teams the freedom to choose which one(s) they want to use.

My point is, there are potentially many, valid ways to express the DTCG composite types in different programming languages. I don't believe the spec should mandate a particular way. I'd therefore argue it's fine to let that be a choice or a configuration option for tools.

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


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

Received on Tuesday, 21 November 2023 16:24:12 UTC