Design Tokens - Color

[Shrinks99]

Proposal

Required reading: Truly Semantic by Donnie D'Amato TL;DR: purpose-priority-property

Color

A three-tiered system with primitives (scale), theme (semantic), and component (semantic) level tokens

• Primitive level: color-red-050, color-blue-600, color-green-900 (implemented in https://github.com/webrecorder/hickory/blob/main/tokens/color.json)
• Theme level: dark-primary-fill, light-danger-border, tritanopia-success-fill
  • Each points to a primitive level token[^2]
  • Used to enable dark, light, or accessibility themes (color blindness, high contrast, etc)
  • The purpose slot in the name defines the theme
  • The priority slot already aligns well with how we define our variables in Browsertrix with danger, primary, warning, etc!
• Component level: button-primary-fill, input-error-border, switch-disabled-fill
  • These remain constant and are just used to style specific components or re-used elements throughout the app
  • The token they target is always a theme level token which can be swapped out with a theme change

[Shrinks99]

Open Questions

I've put a reasonable amount of thought into this over the past year or so and most of the above comes from my Obsidian document, but I think the "component level" is the least fleshed out part of this and deserves some extra thought, especially regarding hover states, etc. How many tokens do we build into the "component level" styles? At what point are we better served not handling that within a design system and instead within app code? These tokens are good for static stuff, but how should we handle interactive states like :hover?

How much (if at all) should we rely on color-mix()? It's potentially a pretty handy way of avoiding having to create lots of definitions for interactive states where we can instead create overall definitions for how much something might lighten or darken. Using OKlch for interpolation will also ensure these state changes are visually uniform.

Because the theme level is getting swapped out based on accessibility settings, does it make sense to actually include the theme name in the token? Leaning on no actually!

[Shrinks99]

Discussion from chat with @emma-sg / Henry's opinion: Yeah, we should probably rely on color-mix() and OKlch a bunch for hover and interaction state sub-palette colours. We finally have good ways of modifying colours on the web, lets use them!

These tools should probably have their own level of tokens (of just values) applied to get uniform hover state lightens and such?

---

I also don't think it makes sense to put the theme name in the second level tokens, instead having groups of different themes with the same named tokens within. The entire group gets switched out with the theme.

[Shrinks99]

We have all the color primitives in!

Next step is the next level up which we may want to be unified between the site and the app and we may not... More thinking required.