- From: James Nash via GitHub <sysbot+gh@w3.org>
- Date: Sat, 11 Jan 2025 01:25:49 +0000
- To: public-design-tokens-log@w3.org
I've literally _just_ read this, so this is a bit of a knee-jerk reaction (perhaps I'll feel differently after sleeping on it :-P), _but_... I have concerns about this proposal: * While I take your point about the prior art and widespread usage and support of JSON Schema, I'd argue that within the domain of design systems and design tokens, the current `{foo.bar.baz}` syntax is more familiar. Mainly because it's inspired by Style Dictionary's syntax, and Style Dictionary has been the most widely used design token export tool for a while now. Newer ones like Cobalt UI/Terrazo support DTCG and therefore also use the current syntax. * Yes, the current syntax requires a little bit of string parsing to detect a reference versus an actual value, but I'm not convinced that `if ( token.$value.charAt(0) === '{' )` is any more difficult than `if ( typeof token.$value === 'object' && token.$value.$ref !== undefined )`. Re-reading #166 and thinking about the resolver spec, I wonder whether "refering tokens in another file" is the right problem to be solving. Clearly, there's a strong demand for being able to split up your design tokens across multiple files - both to keep things manageable when you have a large number of design tokens, and to do stuff like theming by varying which files get included by some mechanism. But that doesn't necesarily require references that point to specific files. In many cases, the intent is to merge all the source files into a single collection of tokens, and _then_ to do stuff with it. This is how tools like Theo and Style Dictionary have been doing it forever and I'd argue the Resolver Spec is another (more advanced) take on that concept too. Resolving design token references doesn't happen until after that file merging process has been done, so there's no need for them to specify a file that a token is in. We can debate whether or not that kind of merge-and-then-resolve-references approach is the "best" way to go, but my point is enabling tokens spread across multiple files can be achieved without changing the current reference syntax. So, considering how big of a breaking change this would be, I wonder if it's worth it. -- GitHub Notification of comment by c1rrus Please view or discuss this issue at https://github.com/design-tokens/community-group/pull/259#issuecomment-2584983347 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Saturday, 11 January 2025 01:25:50 UTC