[kaelig]

A few members and myself have commented to explain in various ways what we're solving.

This methodology is being used by most frontend and design teams at medium/large companies. There's a real need for a way to communicate design decisions between humans, teams, and tools at scale. it requires a lot of custom plumbing at the moment and smaller teams don't always have that luxury.

The spec is here to unify the tooling landscape around a single format, which in turn will accelerate innovation in this space, and democratize the methodology all the way to smaller teams.

[motorest]

I'm sorry, you wrote words but they don't say anything. They sound like machine-generated nonsense.

Can you actually provide a concrete example of a concrete problem you want to solve with the token-based UI initiative? Write your answer following the STAR format, and leave the buzzword bingo out.

If you cannot explain your problem then this is a very clear tell that it might not exist at all.

[kaelig]

> They sound like machine-generated nonsense.

Fair! Perhaps I should have used an LLM to de-bullshitify my message...

Let's walk through a common scenario:

Design tool A has brand colors coded in hexadecimal, those have no name, they're just hex values.

Design tool B has colors named in CamelCase, values in HSL.

Codebases A, B, C have colors in RGB, named the same as in Design Tool B.

Codebase D has colors in Hex8, with their own naming convention.

100s of developers copy/paste values from old and new designs over the span of several years.

Codebases now have 50 shades of the "primary blue" scattered around. Now user experience feels disjointed at best, confusing and hostile at worst.

Engineering design collaboration is tough as no two tools and teams speak the same "design language".

Say a team wants to implement a new feature across multiple codebases where styling and naming are all different.

Lacks of re-use and poor communication leads to entropy, which leads to poor quality and slower delivery.

Design tokens are the interoperable layer that help define a common language across people and tools and improve what I described above. (for those familiar with DDD, there are a lot of similarities)

The spec itself is baking this into the entire toolchain so it's available to teams by default, without requiring as much custom tooling.

PS: the scenario above may seem extreme to some, but it's _extremely_ common at medium to large companies with no established design/engineering processes.

[bmelton]

Great answer. In your scenarios, let's say OrangeCorp has their 'brand-orange' color token. They've defined it as the hexadecimal `#FFA500`.

Engineer Bob implements it as `hsl(39, 100%, 50%)` in a web project because the loading state requires shifting the color values, and he has a library that works with HSL but doesn't work hex.

What do you store for the source of truth? Are we just storing the hex value, and deriving translations from that? Or are we storing 'brand-orange' with a map of "hex: FFA500" and "HSL: 39, 100, 50"? Does the specification have an opinion?

[kaelig]

The "fun" part with HSL is that RGB->HSL->RGB conversion doesn't always land back on the initial value (and that's why I discourage using HSL altogether).

In orgs without design tokens, I forgot to mention there's also number of folks using the color picker from their OS to grab what they think will be the right color, sometimes even on lossy images like a PNG, JPG, GIF... and that's how you end up with the 50 shades of blue.