Re: [community-group] Value Definition Syntax for a tokens type (#78)

Thank you for your suggestion. I think it definitely makes sense to reuse existing standards and conventions where possible and not reinvent the wheel. We do already draw some inspiration from CSS (e.g. the `px` and `rem` units for `dimension` tokens).

However, we also need to be mindful that:

1. Design tokens are intended to be platform-agnostic. They may be translated into various programming lanugages (e.g. CSS, Android resource XML files, iOS Swift code, etc.) and also used in UI design tools (e.g. Figma, Sketch, etc.) and, potentially may be used in other contexts too (e.g. rendered as visual previous in a style guide). That doesn't mean we can't mimic CSS's syntax where is makes sense, but it might mean we restrict ourselves to a sub-set of what CSS can do because other tools/platforms lack equivalent features. Or, we at least need to specify what fallback behaviour should be in tools/platforms that don't support certain kinds of values.
1. Unlike CSS, our format is JSON-based. Sometimes it therefore makes sense to use more JSON-like values than CSS ones. For example the cubic bézier example you cited. Fundamentally, it's a tuple with 4 numbers. In CSS that's expressed as a function `cubic-bezier(...)`. If we were to use that directly in our spec, it would need to be something like a string value like this: `"value": "cubic-bezier(...)"`. However, we've chosen to [use a plain JSON array containing number values](https://design-tokens.github.io/community-group/format/#cubic-bezier). That saves tools need to parse the string to get those 4 numbers.
1. We're currently aiming at a v1 spec, so we want to focus on the most commonly used things. Adding too much complexity now would delay completing that v1 and also risks adding things that hardly anyone uses. Our preference is to start small and then iterate in future spec versions based on how people end up using the spec. It's easy to add more ways of expressing values in future versions, but we can't change or remove existing ones without it being a breaking change.

Does that make sense?

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


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

Received on Monday, 13 December 2021 16:39:50 UTC