Re: [community-group] [RFC] Format specification (#1)

While I agree that it would make sense for adjustments to become part of the spec - as @mirisuzanne rightly says, that can help make the relationships and intents that underpin the system more explicit - I suggest that we tackle them a bit further down the line. As it stands we don't even have a basic spec for file format, permitted types of values, etc. I suggest that those a prerequisites for more advanced functionality like adjustment functions.

It's also conceivable that tools (assuming they all begin supporting the format we define) could provide a work-around until the format "natively" supports adjustments. I'll outline a couple of examples to show what I mean:

**Modular scale of text sizes**
A design tool like, say, Sketch might one day be able to import all font size tokens from a file using our new format. In the absence of math operators, the file would therefore need to contain the pre-calculated values. However, from the perspective of a design system team that authors and maintains the "single source of truth" design token files, they may prefer to only be storing the inputs need to generate the font sizes - i.e. a base font size and a multiplier (and perhaps min and max points on the scale).

In this scenario the design system team could maintain a "source" token file that only contains those values. But, they could use a build process to generate a "dsitribution" token file which is then made available to consumers of that design system. Imagine if, for instance https://www.modularscale.com/ (or better yet, some kind of CLI utility with equivalent functionality) could load a token file, generate a scale and save out the values to a new token file. That could work.

**Color palettes**
In a similar vein, if tools that manipulate colors (e.g. https://www.modularscale.com/) gain support for our standardised format, they could be fed with some "source" token values and then save out (possibly to a new file, if desired) calculated "distribution" token values for other tools to then consume - or further manipulate.

So, with a setup like that you could potentially maintain a minimal set of source colors and adjustment parameters and then lean on tools to generate all the tints and shades needed for the full palette.

-----
It's exactly this kind of interoperability that I hope we can unlock by defining a standardised file format for design tokens. I love the idea that one day I'll be able to mix and match all kinds of tools to create, maintain and also use design tokens. :-)

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

Received on Tuesday, 20 August 2019 09:41:13 UTC