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