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

That’s a fantastic write-up, @ilikescience. I also enjoyed your post about your design API. I found the GraphQL interface quite straightforward. In that post I spotted the `category` relationship field, where I presume you’ve gone down this road quite a bit farther. That kind of experience will be super helpful.

### Typing

I can see how typing might be helpful. I would be interested in seeing this explored more. In a CSS-like markup, I could imagine at-rules and functions accomplishing this. Tho, I like that you are focused on the _should we_ before the _how do we_. It is harder for me to separate them. 🤷

### Uniqueness

Regarding `const` and the prompt “_What are use cases for defining a token more than once?_”:

I would not be in favor of `const` for style rules, i.e. selectors paired with a block of styles. Correlating `const` with rules seems problematic to me, as CSS rules are better compared with JS `class`, `Class.prototype` prototypes, and `{}` objects.

To the point of the prompt; if I interpret a style rule like `token { color: black }` as `const token = { color: 'black' }`, then I’m unsure what an override to `token` looks like in CSS when I want to assign a background color to the token definition. In JS this might look like `token['background-color'] = white`, while in CSS it would look like another rule — `token { background-color: white }`.

If `const` meant the selector could only be used once, then the interpretation would more closely compare with `const body = Object.freeze({ color: 'black' })`, seems more restricting than what is possible in either CSS or JS. 🤔

### Aliasing

I think aliasing is a must-have, tho most-crucial for design systems over time. Aliasing can happen in the start, as in primitive tokens like you described, and also in higher order components. Like, sometimes things are referred to by how they look; sometimes things are referred to by how they function; and sometimes things are referred to by how they relate to other things. And on and on. Things get referred to multiple ways within a design system, usually based on history or context. Aliasing can seem antithetical to order and consistency, but consistency gets super hard the more components get created and the more time passes.

Most design systems that I have seen up-close start out as a _state of the union_, often combining some new desires of the designers or developers with a larger set of existing patterns in production. The new and old are best paired with aliasing. Then, in the course of putting the design system together, the team makes choices over how to group color tokens along some axis of intensity, or how to group spacing by some multiple. And then later in the course of using the design system, exceptions are made and whole concepts change or get reimagined, and new pattern emerges. The new and old are best transitioned with aliasing.

Aliasing for all the things!

### Order dependency

I probably have more to learn here. I would expect it to resolve a dependency tree like JS imports; e.g. Two JS files can both import from the same third JS file.

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

Received on Monday, 20 July 2020 18:38:34 UTC