- From: Travis Spomer via GitHub <sysbot+gh@w3.org>
- Date: Thu, 11 Jan 2024 16:21:56 +0000
- To: public-design-tokens-log@w3.org
The way I see it, design tokens as both a concept and a file format really only make sense if they're used end-to-end. If you leave an engineer long enough they will inevitably come up with their own form of design tokens: if you remove the standardization bits, apps have been using design tokens for decades, for as long as apps have tried to have visual theming capabilities. Both designers and engineers already have tools that accomplish similar things (color styles in design software, CSS variables, platform-specific resource files, custom tables of color values and font sizes, etc.), and they already use them. The problem that design tokens attempt to solve is that often there's little to no standardization for that handoff from designer to engineer: the way the Figma color styles are set up does not match the way the CSS variables are set up, for example. Details get lost in translation and bugs show up and engineers have to keep asking "what about if it's hovered *and* focused?" Design tokens as a concept are an attempt to get the designer and the web engineer and the iOS engineer all speaking the same language, clearly. From my perspective, *almost all* of the value of design tokens comes when you use them end-to-end. -- GitHub Notification of comment by TravisSpomer Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/102#issuecomment-1887515813 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 11 January 2024 16:21:59 UTC