Yes to everything you say, except for "option/decision/component" as that's up to the users.

The spec is acting just like how CSS doesn't tell you how to name and nest classes.

Why call it tokens instead of variables?

A few names, including "design variables", were considered in 2014 when Jina Anne and Jon Levine (Salesforce) coined the term.

I wasn't in the room when they made the decision, but perhaps they'll pop into this thread and tell us!

because they are constants, not really variables?

They can be constants, but not always: a design token can mutate based on device, light/dark/high-contrast mode, viewport size, user preference, locale, brand, product, theme, etc. This mutation can happen at runtime or at build time depending on the use-case.

Examples: - "primary button background color" may be different across light and dark mode - "header height" can vary across small and large viewports - "user avatar background" may be defined by the user themselves - "brand primary" may change for re-usable UI components based on the brand they're used for

light/dark mode as user setting is a variable, current viewport too. But the dark primary button background color and light primary button background color are constants in a design system.

> "user avatar background" may be defined by the user themselves

Even tho you are the founder of the Design Tokens W3C Community Group, I will have to disagree with you on this. That's not a design token, just a variable/user preference and its lifecycle has little to do with the design architecture of the product.

> But the dark primary button background color and light primary button background color are constants in a design system.

They are not necessarily constants, and _could_ point to a theme's value, or even be generated on the fly.

> Even tho you are the founder of the Design Tokens W3C Community Group, I will have to disagree with you on this. That's not a design token, just a variable/user preference and its lifecycle has little to do with the design architecture of the product.

That's a choice you can absolutely make for your use-case.

A design token _can_ be a named design property with a dynamic value, and sometimes a fallback. User preferences _can_ feed values into existing tokens.

The important part is that design and engineering are speaking the same language when referring to these – you're free to tokenize these or not.

Why not call them constants then?

Tokens is a really terrible name given the strong expectation that anyone with a computer science background has around the meaning of "token".

Yeah... auth tokens, resource tokens, rate limiting tokens, monetary tokens, LLM tokens, parser tokens, etc... you might as well name it "thing". It's about as bad as "node".

New jargon lets you avoid overloading existing terms and it adds specificity.

When someone says design token, you know they're talking about this. They don't have to say "variables" or "constants" + extra explanation that narrows the reference to the TFA concept every time they want to refer to the concept.

We do this so often in programming that you take it for granted. You're using dozens of words that weren't used 10 years ago.

Hydration is a good example of one of those words in the webdev space.

ok, so the concept of layers is built in but not which layers