Spacing tokens #2917
vnys
started this conversation in
Design tokens
Spacing tokens
#2917
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
In his article Spacing in design systems Nathan Curtis introduces a vocabulary for spacing in user interfaces, where he uses specific names to identify combinations of vertical and horizontal spacing based on the ratio between them, as well the axis the spacing token is intended to operate on. In the EDS we have adapted these names in our spacing tokens, in addition to borrowing some concepts from Eric Singhartinger’s Token Studio starter file from the Token Studio for Figma Quickstart presentation on YouTube, specifically the three categories which he calls “page”, “container” and “selectable” – and that we call “UI shell”, “container” and ”component” respectively1.
The most basic spacing tokens are meant to be used either vertically or horizontally, and the scales are called stack and inline respectively. In CSS they are called block and inline, and we have not decided 100% that we think it’s a good idea to introduce a different name for designers than what we already have in CSS. Stack might be easier to understand, since we stack things on top of each other, but there’s some value to using the same language between designers and developers as well. When Figma introduced a CSS concept called leading trim and called it vertical trim, that’s an example of a missed opportunity for a common language.
In the table below, and in the composition tokens, vertical precedes horizontal, This, too, is because that’s the order in which CSS shorthand values are resolved. If, however, this proves to be too mind bending for people used to thinking about horizontal before vertical, myself included, that’s something we can change.
The reason we have two scales, when they both have the same initial values, is that when we decrease the density, the vertical scale has a steeper decline than the horizontal one, because the main reason we need density modes is to fit more table rows in the UI shell at the same time. Making the components take up less space horizontally is mainly to ensure that there is at least some harmony between the vertical and horizontal spacing – not to make each and every component look like a scaled down version of the default density original.
Spacing tokens that only have one value, use normal single value tokens. Tokens that have two values, however, such as tokens where the name is based on a ratio between vertical and horizontal values, use composition tokens. Composition spacing token values are aliases referencing single value tokens as aliases.
Component tokens
The base spacing tokens, intended for use in components, use 4 pixel increments and t-shirt sizes, and have the following values in the default density mode.
And the following values for the composition tokens. The value of the vertical spacing is used to determine the t-shirt size, where
sm = 8,md = 12andlg = 16. Note that sm in one scale does not translate directly to sm in another scale, which explains why we haven’t used xs, sm and md as the default names for the composition tokens. This follows the same principle as with typography, where a small heading is larger than a small paragraph. This decision is also up for debate if anyone has strong feelings about that – but let’s postpone that until the container tokens and UI shell tokens are finished to get the full overview.This is what we have so far, next up are UI Shell and container tokens.
Footnotes
Component is not the best name here, but I’m still not sold on “selectable”. But a container is also a component, so perhaps atoms and molecules can be used instead. ↩
Beta Was this translation helpful? Give feedback.
All reactions