🪙 Expand token types

Our community would love to see some new token types added that match existing native functionality in Figma that we currently don't support:

• Alignment (flexbox/autolayout position)

  • horizontal and vertical gap with autolayout wrap

    Use case: User wants to tokenise/control the alignment of the buttons in a container component. In Figma the user can achieve this by controlling the auto-layout by setting it to "align top-right" for instance.

• Various typography "property" tokens

  • textAlign

  • tabular numbers (font variant numeric in CSS)

  • ELSE

• Border width tokens

  • with multiple values

• Breakpoint/container query sizes

• Component/variant

  • Currently, it’s possible to use boolean tokens in Token Studio (TS) to change a layer’s visibility, but not to define component variants. This would allow users to manage the boolean tokens in TS. Assign them to the appropriate component variants and eliminate the need to switch over to Figma for manual assignment. Since we already manage our tokens within TS, having the ability to control component variants from the same platform would streamline our workflow and improve efficiency.

• Full Width property for the Sizing token

  • Fill container - full width (100%). Just as we have fill container in Figma, users would also want to control this property from a token.

• Corner smoothing via percentage

• Animation properties, such as

  • Duration

  • Cubic Bezier

• Grid Styles

• Multiple fill or multiple layer tokens ( #152)

These types are currently defined in the DTCG spec

• Transition (Github Issue #1748)

• Gradients

😬 The reality

We are trying to align our offering with the DTCG W3C specifications, but their guidelines are not as inclusive as we are in supporting the way designers work in Figma and historically have been slow to update their specifications.

💭 How might we...

Add more token types to enhance the workflow of designers, especially those working in Automated workflows that might not yet be a part of the DTCG W3C specifications of accepted token types?

Could there be a way for the creation and organization of tokens to be less dependant on token type? Perhaps we define the token type when creating/editing tokens from a standard process instead of token type specific process which would provide more flexibility?

💬 Feedback that is valuable

• Which of these token types would have the greatest impact on your day-to-day?

• What workarounds do you have?

  • For example, we don't offer an alignment token, how do you communicate that decision today?

↔ Related topics

• Expand gradient color support → Jump to post