- From: Steve Dodier-Lazaro via GitHub <sysbot+gh@w3.org>
- Date: Thu, 19 Jan 2023 07:30:37 +0000
- To: public-design-tokens-log@w3.org
> Ideally tools only hide or ignore parts of a tokens file because they recognize the content and know that it is irrelevant for their context. > > hidden because known to be irrelevant vs. hidden because unknown The problem with that in a library, API or standard maintenance context is that it means many consumers must be aware of changes made by one upstream. If a tool doesn't support a new feature, and finds unknown attributes on a token, it would be better if that tool didn't suddenly implode. If the tool's user community finds it irrelevant for the tool maker to code that the new unknown property is indeed irrelevant, that's time saved. We know how hard it is for FOSS devs to find time to maintain their code, so removing the need for tool makers to target the full tokens spec feels like a healthy thing to me. Applied to this situation, I think it's ok if there's no fixed standard for what conditional / contextual token values can exist. Token writers will come up with ideas. Tool makers too. Of course, there could be a preset in the standard that grows as token usage matures, but I wouldn't make it a necessary thing to support for tool writers. Newcomers who want to produce a new tool will also be better off if they can focus on supporting the core of a token and set aside advanced features. Having fewer mandatory features in the spec makes the barrier to entry for new players lower. -- GitHub Notification of comment by Sidnioulz Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/169#issuecomment-1396549471 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 19 January 2023 07:30:39 UTC