Codex components and layouts will be sized and spaced following a predefined scale derived from the system's base spacing unit (please see previous discussions in T288026).
Once defined, the system's size and spacing scale will be translated into size tokens, which will ensure the application of system-compliant dimensions.
As a designer, I need to have access to the system's size & spacing scale, so I'm aware of which spaces and sizes I can apply when creating system compliant designs.
As a theme developer I'd like to have free decision of which CSS units I'm using. For example a rem only theme for a Wikimedia microsite.
We try to achieve three different success criteria at once here:
- Developer Experience: A clear and expandable scale nomenclature. Also that devs don't have to care about sizing in their Vue code. See T324367: Enable Codex tokens to work with different font sizes
- Themeability: A simple way to provide themers to have control over the scale and at the same time the units used in one place. See also T296689. To be expected in a web theme:
- All rem
- A mix of px and em
- A mix of px and rem
- (not aimed for to advertise for in regards to a11y, but possible: all px)
- Accessibility: A full text-zoom able interface the Wikimedia way – font-sizes and scaled font size box impacting relatively sized properties, like width, height, max-width, max-height.
Acceptance criteria (or Done)
The size scale (or scales) should provide us with a set of tokens that allow design contributors to:
- Space elements/components internally
- Define the space around or between elements
- Shape the element's heights and widths
In Figma, size and spacing tokens will be documented as components that designers will be able to reuse for specification.