James Nash

@TravisSpomer >about half of people find the concept confusing, and it's not split down engineer-or-designer lines. That's really interesting! Thanks for sharing. Makes me think there could be a market...

I agree this could be useful and could double as a versioning field (something we've been meaning to add anyway). We could have the spec version that the file conforms...

Sorry for the delayed response. You raise some valid concerns and I think our spec does perhaps need to be more explicit about expected fallback behaviours for tools that can't...

@roblevintennis If you're only working with CSS, then it's absolutely fine to just use CSS custom properties. Not everyone needs to use the format we're proposing here. Design tokens the...

@jjcm Making more example files is on my to-do list. So far there's only the ones that @splitinfinities already pointed to. I should stress though that the spec itself is...

In the current spec, tokens can either have actual values - which, to use your terminology, would make them an "option" or "primitive" token - or they can be references...

Excellent points. The lack of support for relative length units like em or rem in many design tools irks me too. Thinking of a standardised token format, I'd suggest it...

Really interesting ideas here! I'm going to throw another idea into the mix: The ability to define "interfaces" (similar to object-oriented programming) for tokens. My thinking is that some of...

I certainly agree that my interfaces proposal is out of scope for an initial version of our design token file format spec. However, since this thread is discussing possible approaches...

@mathieudutour >If I understand correctly, instead of having variants apply to potentially all tokens, an "interface" would only apply to a fix set of tokens Yes, that was my thinking....