chore: adopt design tokens

[SethFalco]

I've been learning about design tokens, and wanted to adopt them in SVGO.dev. This seems like a good workflow, so we'll be retaining the changes.

There will be a delay in getting this merged while the design tokens are actually defined, so this will be a draft for a while.

Publishing Design Documents

We're in the process of migrating from Figma to Penpot. When this transition is done, the Penpot document will be public, and linked somewhere. (Perhaps the README or a contribution guide.)

Design Tokens Format

We'll only use tooling that supports the latest Design Tokens Community Group (DTCG) draft — not any other standard for design tokens. Penpot supports this standard natively, and the style-dictionary package can convert this format to CSS variables.

I did explore @csstools/postcss-design-tokens too, but this only supports the style-dictionary3 format, which wasn't compatible with the the output from Penpot. Using style-dictionary directly appeared to offer a much better experience anyway in my opinion.

Proposed Workflow

1. Our designer will now define variables in the design document. (Penpot/Figma)
2. These are exported as "design tokens" to the repository. For now this is done manually by a developer, but we'll investigate if this can be done by the designer directly.
3. Pre-build time, these tokens are converted to CSS variables.
4. During development, we just use these CSS variables as normal.

Before, from my perspective there was no step 1. Meanwhile, step 2 was to open the design and copy and paste discernable variables one-by-one into CSS variables or to hardcode them. It wasn't an awful workflow, but the new workflow seems more streamlined.

File	Description	Committed to VCS
tokens.json (left)	Exported design tokens from Penpot.	✔️
_variables.css (middle)	CSS variables generated pre-build.	❌
custom.css (right)	Consuming the generated CSS variables in our project styles.	✔️

Important

This is a proof of concept — which variables should be tokens and naming conventions for the design tokens have not been defined yet, and we may still reconsider the workflow.

How to Contribute?

This gets a little pedantic, but we should consider how this may affect contributing to the repository. This isn't a blocker, but I think it's worth posing the question. Especially if it's worth being explicit that we welcome changes, etc.

The old approach was very contributor friendly, since the repository was a pseudo-source of truth for these CSS variables. Now, the source of truth for these variables reside in a design document, maintained outside the repository — it introduces complexity for contributors who may want to propose design changes.

• Are contributors encouraged to hand edit ~/tokens/tokens.json? Fortunately, the format is very simple.
• Are there any good development tools for editing token files in popular IDEs?
• Do design tools like Penpot have any native features for proposing changes? Though, we shouldn't assume users would be willing to create an account for this.

No matter what they do in their contribution, it's not a big deal as if approved they can be synced up with the design, or amended before merging (preserving authorship).

I just want to make sure contributors know they're welcome to propose changes, even to tokens.json, even though the conventional workflow is that Penpot/Figma is the source of truth for it.