Would it make sense to have some predefined standard extensions? In general, border radius, padding, width, and letter spacing are all dimensions, but their meaning is quite different. That said, width and height may be considered different by some people or just special cases of “size” by others. On the web, this idea of “size” vs separating by width and height also is supported by logical properties such as inline-size and block-size which can vary in physical interpretation depending on language writing direction.

All this to say that perhaps an extension to the spec or a note on “common extensions” would allow better support of cross-tool collaboration in this way.

For example, panda-css defines tokens grouped based on categories (see https://panda-css.com/docs/theming/tokens#token-types) as does tailwind via a css variable naming convention (https://tailwindcss.com/docs/theme#theme-variable-namespaces). The current approach I would assume would be to either rely on the token group names (which violates section 6 of the spec “Because groupings are arbitrary, tools MUST NOT use them to infer the type or purpose of design tokens.”) or else to use a custom extension:

“$extensions”: {
  “com.panda-css.token-types”: “radii”
}

“$extensions”: {
  “com.tailwindcss.namespace”: “radius”
}

My proposal would be to define an extension such as

“$extensions”: {
  “org.designtokens.usage”: “radius”
}

Both tools could then choose to support their own extensions but also respect or even output the standard usage extension (or other name) for how the dimension is intended to be used.

Originally posted by @TzviPM in #223