W3C home > Mailing lists > Public > public-design-tokens-log@w3.org > March 2020

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

From: akalenyuk via GitHub <sysbot+gh@w3.org>
Date: Wed, 04 Mar 2020 21:09:59 +0000
To: public-design-tokens-log@w3.org
Message-ID: <issue_comment.created-594844027-1583356198-sysbot+gh@w3.org>
Hey everyone!

I'm one of the authors of [Puzzle Tokens plugin](https://github.com/ingrammicro/puzzle-tokens) for Sketch which allows tokenization of prototypes via CSS style preprocessors, specifically Less/Sass. I'm following the conversation and wanted to share some experience that we had while migrating from hardcoded values to design tokens in our company. 

We started with JSON as a way to store the specification but after several iterations we came to a Less/Sass based design token spec format from which we benefited in so many ways:
* Well documented and easy to grasp syntax which extends standard CSS syntax
* Native support for parameters (which we used as tokens storage) and the ability to group it via array (which helped keep it clear and save some space)
* Built-in functions to manipulate design tokens values, while still keeping it in formulas. For one thing, it's color manipulation functions, so now it's much less 'magic numbers' in the design token spec and you can always reverse-engineer the logic a designer has put when introduced a new color. 
* Ability to describe and store rules of application of tokens via CSS selectors, which suits very well for all modern prototyping tools like Sketch and Figma as you tend to organize layers via nesting and grouping which matches to a DOM tree. Strictly saying, It's not supposed to be a part of design tokens spec per se, still it is really handy to be able to apply a token value to a Symbol in the same file, if you want to.
* Storing design tokens in a format that is natively readable by the development team, so there's no need in extra logic to interpret as it can be naturally taken by standard Less/Sass preprocessors.
* Ability to structure the design tokens via keeping separate pieces in different files

Lots of pros but there are cons for sure. For example we didn't have a chance to solve it for mobile platforms as we mainly work web.

Hope that makes sense and helps!

GitHub Notification of comment by akalenyuk
Please view or discuss this issue at https://github.com/design-tokens/community-group/issues/1#issuecomment-594844027 using your GitHub account
Received on Wednesday, 4 March 2020 21:10:01 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 4 March 2020 21:10:02 UTC