[community-group] Add "Option" or "Primitive" tokens, and expand on token inheritance for "Alias" tokens in groups (#145)

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

== Add "Option" or "Primitive" tokens, and expand on token inheritance for "Alias" tokens in groups ==
One thing I miss in this specification draft (but maybe there is a valid reason for it) is to capture more deeply how token inheritance works, what are the two main token clusters, and how groups play an essential part in token inheritance.

Tokens that inherit their value from other tokens are called "alias" tokens. However, I am missing the name of the tokens which cointain the actual value. For a few years, I've been calling these types of tokens "options", but a perhaps a better name could be "primitives". Another word I've seen circulating for this concept is "global" but I don't think "global" captures the true meaning of this concept.

I believe it's critical to define a name for these types of tokens as they are the core of everything. When defined, they help us understand better how tokens interact with each other when groups are formed in a token system.

In my opinion, "option" or "primitive" tokens are those which exclusively have raw values (when talking about single tokens), or objects with "exclusively" raw values (when talking about composite tokens). 

On the other hand, "alias" tokens should never possess a raw value, instead, they always refer to an existing "option" token.

When dividing tokens into these two main clusters, some rules, or "best practices" should be introduced for naming tokens. The name of an "option" token, for example, should be completely agnostic. "Alias" tokens, on the other hand, should give more meaning to the token.

Option token's main purpose is to create a bucket of available options within a cluster, and prevent values from repeating within a token system (main scope).

There should, therefore, be "option" and "alias" tokens in every token group. Alias tokens will always inherit their value from their direct group or any other group within the same scope.

The design token tools should only use option tokens to satisfy the references in alias tokens, but should not render "option" tokens as output during translation.

Alias tokens can only refer to tokens within their group's scope. So for example this is possible:
`{
  "color": {
    "50": {
      "$value": "#ffffff",
      "$type": "color"
    },

    "brand1": {
      "50": {
        "$value": "#000000",
        "$type": "color"
      },

      "primary": {
        "$value": "{color.50}",
        "$type": "color"
      },

      "secondary": {
        "$value": "{color.brand1.50}",
        "$type": "color"
      }
    },

    "brand2": {
      "50": {
        "$value": "#0000ff",
        "$type": "color"
      },

      "primary": {
        "$value": "{color.50}",
        "$type": "color"
      },

      "secondary": {
        "$value": "{color.brand2.50}",
        "$type": "color"
      }
    }
  }
}
`

But I would not be able to access a color declared in brand1, from brand2, or vice versa.

Once we have defined "options" or "primitives", and "aliases", one could argue that there is a third type, which I have been calling "scoped" or "component" tokens. These tokens are essentially a sub-type of the "alias" tokens, as they are only able to inherit a value from an option or an alias token within their own scope. Because of this, we might not need to have this third token name and the spec should work fine with only the two main clusters; "options" or "primitives", and "aliases".

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


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

Received on Sunday, 19 June 2022 18:14:08 UTC