Re: [community-group] Make whitespace invalid in token names (#216)

@kaelig & @drwpow from what I recall, (part of?) the intent was to avoid naming clashes when token names are exported as code by translation tools (e.g. Style Dictionary, Terazzo, etc.).

In JSON property names are case sensitive and mmay contain whitespace. So, you could have valid DTCG file like this:

```jsonc
{
  "My token": { "$value": /* ... */ },
  "My   token": { "$value": /* ... */ },
  "my-token": { "$value": /* ... */ },
  "   my     token    ": { "$value": /* ... */ }
}
```

...and those would be 4 different tokens.

However, a lot of programming languages have more restrictions and/or naming conventions for variable names , so when exporting to code, those token names will often end up being kebab-cased, or camelCased, or have some other kind of transform applied to them.

Unfortunately, that can sometimes lead to different tokens names that are valid in JSON/DTCG turning into the same output name. E.g. camelCasing the example above, might product the same `myToken` name for all 4 design tokens in the above example.

Also, if I'm not mistaken, in JSON a property name could be entirely whitespace or even an empty string. So this would technically be valid too:

```jsonc
{
  " ": { "$value": /* ... */ },
  "": { "$value": /* ... */ }
}
```

How would you export that to a JS variable? Or, display as a Figma variable name?

I _think_ there was a suggestion that perhaps, token and group names should be case-insensitive and ignore whitespace. So, `"  my token   ", "mytoken", and `"MyToken" would all be considered equivalent. And then, if the were duplicate normalised names within the same group, that should be considered an error. So, then the 2 tokens in this example:

```jsonc
{
  "My token": { "$value": /* ... */ },
  "My   token": { "$value": /* ... */ },
}
```

...might have their names normalised by lowercasing and removing whitespace, which could lead to `mytoken` in both cases and should then be considered an error by a DTCG parser. However, the concern was that this would create more complexity for DTCG parsers. Especially, if you consder references too:

```jsonc
{
  "My token": { "$value": /* ... */ },
  "alias token 1": { "$value": "{mytoken}" },
  "alias token 2": { "$value": "{my-token}" },
}
```

...should both alias tokens be valid and point to `"My token"`?

So, I think the idea was, it might be easier to impose limitations on the names of tokens (and groups) in DTCG file to avoid needing to deal with those kinds of edge cases and complexities.

@ChucKN0risK and @dbanksdesign may recall more details and be able to provide additional rationale. 

Personally, I've always been on the fence about this one. Looking at it with fresh eyes now, I do wonder if this is something we can't just leave as is, or perhaps just impose fewer restrictions. Given that there's now quite a few DTCG tools and files out there in the wild, this could be quite a big breaking change for folks. I know the spec is still an editor's draft, but I'd argue it's become a kind de facto standard already, so we should tread carefully.

Perhaps names that are _only_ whitespace should be forbidden, since they're difficult to display in a meaningful way in a GUI (e.g. in a design tool) or export to code. I doubt anyone would miss the ability to name a design token `"   "`.

There'd still be the potential risk of naming clashes when exporting to code, but I think that's something that export tools could detect and warn/error on (I _think_ Style Dictionary already does this). Also, we could include a _recommendation_ in the spec that file authors avoid choosing sibling token/group names that only differ in case, whitespace or separator characters like `-` and `_`, which are likely to be removed or converted when exporting to code. Tools that let you create or edit DTCG files could also discourage or prevent that kind of thing.



 Or, at least,


-- 
GitHub Notification of comment by c1rrus
Please view or discuss this issue at https://github.com/design-tokens/community-group/pull/216#issuecomment-2584948576 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 00:20:40 UTC