4 ms·

because they are constants, not really variables?

seanhunter 2y ago
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".
- rendaw 2y ago
  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".
kaelig 2y ago
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 2y ago
  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 2y ago
    > 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".

rendaw 2y ago
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".

kaelig 2y ago

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 2y ago
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 2y ago
  > 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.