Jerome Farnum

I’m currently attempting to form some nomenclature for this at my company and what I’ve been pushing is _token source files_ for the canonical `.tokens.js` files and _token documents_ for...

Perhaps off topic for this thread, but additionally we’re calling the selected collection of token source files required to render a specific token document (e.g. base + mobile sizes +...

> We call them "token JSON" or "token source files." Collectively they're the "source of truth." When we distinguish between files in this format and our original format, we use...

At my last company I put together something similar to the `$conditionalValues` @romainmenke is proposing above, to solve for nearly the same requirements (if not an identical solution, the same...

> Using `$extensions` for this use case is discouraged by the spec. It should be solved with multiple files or in the spec itself. Very fair point. > > At...

I wonder if this concern is something better tackled using `$extensions` records. While I certainly could see some teams desiring this level of tracking for their tokens, I would also...

I’ll leave the colorspace discussion to all you wizards that know far more than myself. To me, the easily much more useful feature that I’m seeing discussed in this thread...

> I think this relates to : #121 and #149 @romainmenke I could see how my request could feel related to the issues you referenced; however, I would hope that...

At EA our `color` tokens support either providing a `string` value for the standard use case, an object for adjusting opacity, or an object for calculated colors. Opacity adjustments like...

> Stronlgy typing the spec could be a great solution to many of the current issues. I really like this from @KyleWpppd `the definition could be either a token has...