Detailed explanation
A rem-based spacing scale is a predefined set of spacing tokens expressed relative to the root element’s computed font size. For example, --space-1: 0.25rem, --space-2: 0.5rem, and --space-4: 1rem represent 4, 8, and 16 CSS pixels when the root font size is 16px. Components use these tokens for padding, margins, and gaps rather than choosing values independently. Arbitrary pixel spacing means scattered decisions such as 13px, 19px, and 27px without a shared system, which can weaken visual rhythm and make maintenance harder.
Under the hood, the browser resolves rem units using the computed font size of the document’s root element, normally html. With a 20px root font size, 0.5rem becomes 10 CSS pixels and 1rem becomes 20 CSS pixels. Unlike em, rem does not depend on each component’s local font size, so nested components retain a predictable spacing reference. A rule such as .card { padding: var(--space-4); gap: var(--space-2); } separates the component’s styling from the underlying spacing values; gap applies when the layout supports it, such as flex or grid.
For accessibility, rem spacing can grow alongside text when the root font size follows the user’s browser font-size preference. However, explicitly setting html { font-size: 16px; } generally prevents that preference from changing the root size. Browser page zoom enlarges both px-based and rem-based layouts, so pixels are not inherently inaccessible. Larger spacing also does not guarantee accessibility: fixed heights, overflow, and constrained layouts still require testing with enlarged text and narrow viewports.
The key interview distinction is that unit choice and design-system discipline are separate decisions. A tokenised pixel scale can be consistent and themeable, while arbitrary rem values can still be inconsistent. Rem adds root-relative scaling; named tokens add governance, reuse, and controlled updates. Teams can override tokens for compact or comfortable density modes regardless of their units. Use the shared scale by default, and document justified exceptions rather than claiming every pixel value is wrong.
Key points to remember
- rem values resolve against the root element’s computed font size, not the component’s font size.
- A shared spacing scale creates consistency; rem units alone do not.
- Root-relative spacing can follow browser font-size preferences when the root size respects them.
- CSS custom properties centralise spacing decisions and support theme or density overrides.
- Pixel-based tokens can be valid; arbitrary, undocumented values are the main maintenance problem.
Common mistakes candidates make
- Assuming 1rem always equals 16px instead of checking the computed root font size.
- Claiming pixels do not scale with page zoom or are automatically inaccessible.
- Confusing the benefits of reusable spacing tokens with the benefits of rem units.
Likely follow-up questions
How does rem differ from em for spacing?
For properties such as padding, em resolves against the element’s own computed font size, whereas rem uses the root font size. Use em when spacing should track local text size and rem when components need a shared reference.
Does rem-based spacing make a layout responsive automatically?
No: rem responds to the root font size, not directly to viewport width. Responsive layouts still need appropriate layout rules, flexible dimensions, and sometimes media or container queries.
When are pixel values reasonable in a design system?
Pixels can be appropriate for details such as thin borders or requirements that should not track text size. A predefined pixel-based spacing scale is also valid, provided the team understands its scaling behaviour and tests accessibility.
Interview tip: Explain tokens and units separately, demonstrate one rem conversion, and finish with the accessibility caveat about the root font size.