🎟️ Phab task 🎨 Figma file

Proposals

In all cases, what’s clear is that all Codex’s spacing and sizing tokens should use values from a single scale based on our spacing unit. What’s unclear is which default or combination of spacing CSS units (px, rem, em) would be most suitable.

A. Create a single spacing and sizing scale, with values that only use px units. Allow unit conversion via a utility (Read full proposal)

B. Create a scale in which each value is captured in different units (px, em, rem) (Read full proposal) 👈🏻 Current direction

Introduction

Codex should both use internally, and provide for external use, a set of sizing and spacing tokens that simplify the application of predefined dimensions to elements and components, and to the space within and between them.

Using modular sizing and spacing tokens ensures the creation of consistent designs and applications, while simplifying decision-making.

The system’s base spacing unit

Screenshot 2022-02-17 at 18.44.56.png

The system’s base unit is the value of the incremental ratio applied to obtain consistent measurements for spacing and sizing.

One proposed value of our system’s base spacing unit is 4px. Therefore, 1su : 4 px, 2su : 8px, etc. The alternative is 16px. With that, 0.25su : 4px, 0.5su : 8px, 1su : 16px

Since the base spacing unit is the central element of the spacing and sizing scale, all the dimension values of said scale would be multiples of 4px or dividers/multiples of 16px. This translates into consistent and balanced spacing and sizing at both a component and layout level.

<aside> ⚠️ Our tokens’ naming structure specifies that “Tokens with numerical values are centered around a default key of 100". That default key should correspond to the central value of the scale: @size-100: 4px. In the current implemented version of our tokens, though, that approach is not followed: 16px and 1em correspond to the 100 value there (see source) The reason is that we can’t get away from browser’s scale, font-size: 1em in HTML defaults and will default to 16px. So we will have to maintain two size scales side-by-side.

</aside>

About spacing tokens

We need spacing tokens in order to define the space within and between components (basically paddings and margins). As mentioned, the value of each spacing tokens is obtained from the system’s spacing unit (4px/0.25rem/0.25em).

Spacing tokens applied to a component. As shown, tokens can specify spacing both in the horizontal and the vertical axis.

Spacing tokens applied to a component. As shown, tokens can specify spacing both in the horizontal and the vertical axis.

Spacing tokens applied to space a group of coponents (e.g. in the context of an application)

Spacing tokens applied to space a group of coponents (e.g. in the context of an application)

Ideally, spacing should be defined using relative units (such as rem or em). All in order to maintain the proportion of components and layouts and correctly accommodate UI spacing in the event of font-size changes. I would personally advocate to just use rem for convenience (they make the translation of design easier) and for accessibility reasons.

Please bear in mind that spacing tokens should not be used to define any other type of measurement aside from space between elements. For example, you would not use spacing units to define the size of an icon, but you could use them to define the surrounding margin. If you wish to define the dimensions of a specific element, then you can use sizing tokens.

About sizing tokens