Theemo v1.0: Design Tokens from Figma into CSS with @property, light-dark() and Color Functions

I released Theemo, the end-to-end design token workflow tool, in v1.0. Part of this release is converting design tokens into modern CSS. While most tools convert them into --your-token-name: <value>; Theemo aims at providing the best technical implementation for the web platform. As Theemo is open source, these conversion are extensions to the widely used Style Dictionary – so you can use them too.

Theemo is now capable to turn these Figma variables (with the use of the Theemo Plugin):

Into:

@property --palette-structure-500 {
  syntax: "<color>";
  inherits: true;
  initial-value: #808080;
}

:root {
  --palette-structure-400: hsl(from var(--palette-structure-500) h s calc(l - 10)); 
  --palette-structure-600: hsl(from var(--palette-structure-500) h s calc(l + 10));

  --layout-background: light-dark(var(--palette-structure-white), var(--palette-structure-200));
  --layout-contrast: light-dark(var(--palette-structure-900), var(--palette-structure-400));
}

The docs contain guides to achieve that:

And a full example to see all of them in action.

Token Sets vs. Constrained Tokens

The background for converting tokens with multiple values (Theemo calls them constrained values) two practices have been established for Style Dictionary: Multiple files (one for each constraint) or single file tokens (with multiple values) (by Danny Banks) and recently explained by Stuart Robson in the Implementing Light and Dark Mode with Style Dictionary as part of the Design Tokens Workflow series.

Here is a comparison:

Criteria	Multi File	Single File
Knowledge	Knowledge is with the file itself (filename?)	Knowledge stays with the token
Reading	You see all tokens for one constraint	You see all constrained values for one token
Authoring	Better at changing values for one constraint	Better changing on a token-by-token basis
Building	Not all conversion of token into CSS are possible (knowledge is somewhere else)	All knowledge is available, every conversion is possible

For most of the time multi vs. single file is a choice of personal flavor and technology can greatly assisst here (using Figma, Penpot or Token Studio). When it comes to token conversion into platform (eg CSS) values, the single file approach shows its advantage, as all the knowledge needed to transform a token already is present on the token.

As Stu mentioned for the single file method he used $mods as a way to store the constraints (which is effectively the same idea as constrained tokens in Theemo).

Looking forward I’m testing design tokens in Penpot and follow along their developments in order to write a sync adaptor for Theemo itself. They provide a design token export that has token sets (along with some metadata) but through their Rest API, tokens are readable in a more flexible form (though based on the same structure).

The challenge with these token sets usually is they are made for human readability but not for machine readability. That translation needs to happen somewhere, either in syncing from the API of a design tool or attaching the metadata from the sets onto the tokens before processing them as explained above. At this moment I’m not sure what’s the most practical one.

Sync Guides Updates

While you are reading about sync. The docs for sync design tokens with Theemo have been updated to separate the guides from the config, which makes both more enjoyable to read.

Great time now to give it a try, if you haven’t yet (No Figma enterprise plan required).

Theming + Framework Integrations

There is more 😱 Version 1.0 also includes a major overhaul of its theming process and integration with frameworks. Head over to the blog post explaining these features.

Get Involved

Happy to receive feedback, help or contributions. Best place is to open up an issue over at Github or start a conversation in the Design Systems Slack, where you can find me as @gossi.

That’s it folks
– gossi