[kaelig]

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

[meiraleal]

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.

[kaelig]

> 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.