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

I really appreciate the inclusiveness behind lax token naming and I am hoping that this can work out. But I am also trying to be realistic and this will cause issues unless properly addressed by the specification.

-------

>I can also imagine that people might make linting tools for token files (similar to ESLint for JS or Stlyelint for CSS). Tools like that could help flag potentially problematic token names early.

>Perhaps they could also be configured to enforce a team's chosen naming conventions. E.g. if @TravisSpomer's team doesn't want to allow emojis in token names they could perhaps configure their linter to flag any tokens that don't adhere to that rule.

This seems highly problematic to me :)

Requiring a 4th tool to make design tokens actually compatible between two systems, whereas design tokens are intended to be the compatibility layer seems counter productive.

Problems with token names are common if you look through the issues on style dictionary.
The fact that they needed to add a couple of features to work around this exposes this flaw, it does not fix it :)

This also introduces vendor lock in issues.
A specific context using dependency tokens will have these dependencies :
- design tokens specification (this is great)
- exact implementation of the translation tool
- internal team convention

If the translation tool is no longer maintained it will not be possible to just find a drop in replacement.

If the team wants to use a different convention it might also not be possible without switching translation tools.

---------

>It's worth noting that in other contexts, like displaying token names in a design tool's GUI or a styleguide website, the "raw" token names could just be displayed directly without needing any conversion.

In my opinion this should be weighted fairly against usage in non GUI contexts.
If a certain specification design choice makes sense for designers in a GUI but causes harm for developers it should be reconsidered.

My fear is that design tokens will remain a fringe feature that too often can not be used by developers.

---------

At the moment I am strongly leaning towards `color: design-token('color.button.light blue')` for a CSS plugin. This embraces that the naming isn't CSS compatible and removes any chance of conflicts.

It has the added benefit that any part of token path can be searched for in a tokens file.

Making this easy to type can be done with editor extensions.

----

Maybe a non normative section can be added to the specification with best practices for translation tools?



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


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

Received on Wednesday, 6 April 2022 21:50:22 UTC