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

Wow. Lots of great activity going on here! It's sparked a ton of questions in my head...

@oscarotero I really like your CSS-like syntax proposals! I'd definitely support exploring that direction more.

---

@mirisuzanne I'm not sure I've fully understood what you meant by "custom groupings". Are you thinking of allowing people to define their own, custom group _types_  for token _values_? I.e. something similar to interfaces found in some programming languages (e.g. TypeScript)? Or did you have something else in mind?

---

@ManeeshChiba How would you expect tools to interpret your proposed "molecule" tokens? Using your example:
```css
typography {
    main {
        font-family: $font-families.display;
        font-size: $sizes.medium;
        color: $colors.primary;
    }
}
```
Is the nesting...

- a short-hand for declaring some tokens whose names share common prefixes? I.e. it's equivalent to something like `typography.main.font-family: $font-families.display; typography.main.font-size: $sizes.medium; ...`
- or, is this like a bunch of CSS declarations - i.e. you`re assining the value of the `$font-families.display` token to the `font-family` property. If so, what is `typography main` selecting?
- something else entirely ;-)

---

@jonathantneal Great points about the different ways we might re-use or build upon CSS syntax. I think you've touched on something interesting there: What are the _concepts_ we might want to inherit or copy from CSS?

Most design token tools to date treat them as key-value pairs. Taking Styledictionary as an example, you might define a single design token in a JSON _input_ file like so:
```
{
    "my-token": "#f00"
}
```
...and it can translate that in a range of different _output_ formats. E.g. the SASS output might be: `$my-token: rgba(255,0,0,1);`, the JavaScript output might be: `export const myToken = '#ff0000';`, and so on.

My (possibly incorrect) interpretation of @oscarotero's original proposal was an alternative, CSS-inspired syntax for expressing same kind of design token _input_ data. So, for instance, a future Style-dictionary-like tool might read such files and translate them into a variety of outputs.

However, what's missing is the equivalent of CSS's selectors and properties. There's nothing that specifies what parts of a UI certain token values should be applied to. (That's assumed to be the job of a designer and/or developer who consumes the (potentially translated) tokens into their project)

It's a totally valid question to debate whether a design token format should let you assign tokens to properties and thus essentially define the visual appearance of a UI, but so far they mostly don't (though Diez is beginning to blur those boundaries!).

If I understood your option 2 correctly, where "we build upon the whole suite of CSS specifications", we'd be making a superset of CSS. I suppose we'd get all of CSS's properties, selectors and other goodness "for free" in that case. But, assuming we'd want to empower people that could write tools that knew how to translate that into something meaningful for completely different platforms (e.g. output native Swift UI code for iOS), I'd expect there to be some substantial challenges. Does native UI code for, say iOS, have an equivalent to the DOM in a web-browser and if not what how would we interpret a CSS selector? Also, would be not be reinventing the likes of SASS and LESS?

I suspect I misunderstood the options in your comment though and you meant something else?

---

@ilikescience Thanks for that excellent write-up! The more I think about it, the more I feel we need to capture and names the _concepts_ we're all talking about. Then we can begin to decide which ones are in-scope for a design token format (at least for v1) and which are not.

As you already know, there's already been some discussion amongst the editors about how it might make sense to begin by defining the "model" or "mechanisms" of design token data first and _then_ worry about what syntax(es) it can be serialised to / de-serialised from.

I feel like your comment is the first step towards being able to define such a model. :-)

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

Received on Monday, 20 July 2020 22:37:26 UTC