[community-group] Prototype composite type usage (#126)

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

== Prototype composite type usage ==
When comparing composite types with regular types the added value of composite types wasn't immediately clear to me.

If I read the draft correctly they are strictly defined groups.
The reason to strictly define which sub values are allowed is to make it possible for other tools to interpret the group as a whole.

So in a way they are a tool to make it easier to consume a collection of values.

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

```css
.foo {
  <something>
}
```

becomes :

```css
.foo {
  font-family: "Roboto";
  font-size: 42px;
  ...
}
```

Only needing to type `<something>` is much quicker and shorter than needing to reference each value separately.

In theory this is awesome!

--------

My concern with this is two fold :

1. this is not implementable in certain contexts
2. this must be implemented (contrary to specification wording)

### Not always implementable

Grouping properties and values makes the assumption that multiple consumers can process this.
Even in CSS this is non-trivial and requires something like mixins.

```scss
@mixin type-styles.heading-level-1 {
  font-family: "Roboto";
  font-size: 42px;
}

.foo {
  @include type-styles.heading-level-1;
}
```

In a CSS stack setup without mixins a user needs to reference each value individually :

```css
.foo {
  font-family: <something>('type styles.heading-level-1.$value.fontFamily');
  font-size: <something>('type styles.heading-level-1.$value.fontSize');
  ...
}
```

This is more elaborate than if design tokens didn't have composite tokens :

```css
.foo {
  font-family: <something>('type styles.heading-level-1.fontFamily');
  font-size: <something>('type styles.heading-level-1.fontSize');
  ...
}
```

And brings me to my second point :

### this must be implemented (contrary to specification wording)

https://design-tokens.github.io/community-group/format/#groups-versus-composite-tokens

> Tools MAY provide specialised functionality for composite tokens. For example, a design tool may let the user pick from a list of all available shadow tokens when applying a drop shadow effect to an element.

This is not true.
There is no way for a tool to fallback to "unspecialised functionality".

If my tool doesn't handle the `typography` type there is no way to correctly consume any value contained in this token.

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

In CSS for example it becomes impossible to correctly reference `fontFamily` using a tool that doesn't support `typography`.

- unclear if this is a string or ident token `Roboto` vs `"Roboto"`
- unclear what the id/path of the token is (`type styles.heading-level-1.$value.fontFamily` ?)

I think at least this specialised behaviour needs to become a requirement.
Which also brings me back to my first point, that it can not always be implemented...

--------

One alternative is to see composite types as typed groups without altering how values/group work or how they are written :

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

Any tool that supports `typography` in a special way can do its own thing.

Any tool that doesn't will still be able to correctly handle the sub values as these follow regular group/value rules.

--------

To sum up, I think this portion of the specification needs to be prototyped in translation tools to make sure it can be implemented or needs to be changed so that it can truly be optional.


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


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

Received on Wednesday, 20 April 2022 10:05:01 UTC