- From: Romain Menke via GitHub <sysbot+gh@w3.org>
- Date: Thu, 19 Jan 2023 08:03:14 +0000
- To: public-design-tokens-log@w3.org
> 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. I strongly disagree with this statement. I am a FOSS dev and I've wasted so much time on software that didn't follow a specification. Either because there wasn't a specification, or because the original author of the software had opinions that differed from the specification. The healthy thing for maintainers is often money and that a community can grow around a tool. For this to happen a tool needs to be reliable and useful in a wider ecosystem. Following a shared specification also ensures your tool has interoperability with other tools. That is the entire point of this specification. If you need 5 tools that each interact with your tokens but each of these 5 only implements 80% of the specification, how much of the design token specification will be implemented and useful to you? You will only be able to use 0%-80% of the design tokens feature set. ----------------- I think you misread my comment :) > 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. I did not mean that tools can not have forwards and backwards compatibility by having good error recovery. They must have these aspects. A tools can not implode when it encounters something unexpected. ----- > I believe there's room in the spec for tokens to have multiple value properties, though without embedding the logic as to what they mean. But your proposal is to obfuscate important and (initially) structured data by applying a string encoding. `$value_lang-el` Tools still need to have general understanding that `$value_` + suffix is a conditional. But by specifying the suffix part as blackbox it is no longer possible to have interop between tools. Tools can not assign meaning to `lang` in your proposal. --------------- > Token writers will come up with ideas. Tool makers too. This is fine and that is why `$extension` exists. It allows anyone to experiment. But following the standard process is important. If someone has a good idea and would like to see wider support across multiple tools then they should open an issue in the DTCG and request the specification to be amended. This benefits everyone. -- GitHub Notification of comment by romainmenke Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/169#issuecomment-1396579793 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 08:03:16 UTC