Re: [community-group] Token ID format is not ideal for consuming in hand written code (#119)

> But when a translation tool has to cover every possible character except `.|{|}` and convert it to something native to CSS, JS, ... it has to be lossy or escaped. Both are undesirable.

I guess I'm not understanding why you're saying those are undesirable. To me, lossy transformations of English concepts into identifiers in code is just very normal. And if your token name is so complicated that it's not immediately obvious how your preferred conversion tool is going to convert it into a valid identifier, and it *becomes* confusing, that seems like one of those "if it hurts when I do that, maybe I should just stop doing that" problems. It seems like a problem that just solves itself without needing additional rules.

(I do agree with you, by the way, that the current naming rules feel too lax! I don't really want to be writing code that can properly handle the inevitable case of someone putting emoji in the token name. My designer colleagues *love* putting emoji in names of things. In our design token system at work, the designers are insisting on lots of tokens with names that are just numbers. Those are very annoying to consume from certain types of code too, but the worst-case scenario is having to type something like `Global.Color.Red["80"]`. If things ever got worse than that, I would just tell them "sorry, no token names that are just numbers," or change the exporting process so that the code exports `Red80` instead, or any number of other solutions.)

-- 
GitHub Notification of comment by TravisSpomer
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/119#issuecomment-1073345933 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 20 March 2022 20:49:56 UTC