Value Definition Syntax for a tokens type

[ariarzer]

It might be very platform specific, but i guess, that VDS (Value Definition Syntax) form CSS fits very well for description the type of the tokens.

For example, if you want to define a color-token, you can write:

  "Majestic magenta": {
    "value": "#ff00ff",
    "type": "<color>"
  },

Or, if you want to define a bezier function, you can use a <cubic-bezier-easing-function> from css-specification.

And that way would work well for the css at-rule @property for define a custom properties (and type os custom properties).

CSS is created for description of interface appearance, like a design tokens too. I guess, that it will be convenient)

P.S. sorry for my not perfect english)

[c1rrus]

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.
2. 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. That saves tools needing to parse the string to get those 4 numbers.
3. 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?

[c1rrus]

The spec editors have reviewed this issue and, given that there's been no further comments, have decided to close this. We thank you for your suggestion, but will continue using our own value formats for the reasons I explained in the previous comment.