Modeling responsive design tokens

WHAT THIS TESTS Whether you can represent a viewport-dependent value as one coherent token and keep responsive logic out of component code.

A GOOD ANSWER COVERS Model the responsive token in the source as a structured value, a map from breakpoint name to value, for example spacing-section with small, medium, and large entries. The build transform expands this into CSS custom properties: define the base value of the property in :root for the smallest viewport, then redefine the same custom property inside min-width media queries for each larger breakpoint. The cascade ensures the latest matching media query wins, so the property holds the correct value for the current viewport. Components reference a single token, var(--spacing-section), and never write media queries themselves; they automatically receive the responsive value. This centralizes both the values and the breakpoint logic in the token output, not in dozens of components.

COMMON WRONG ANSWERS Generating one token per breakpoint, like spacing-section-sm and spacing-section-lg, forces every component to add its own media queries and choose, scattering responsive logic everywhere. Hardcoding breakpoint values directly in components defeats tokens. Forgetting a base value means small viewports get nothing.

LIKELY FOLLOW-UPS How do breakpoints themselves stay tokenized? Store them as tokens too and use them in the media queries. What about container queries? The same model applies, redefining the property inside container queries. How do you avoid specificity issues? Redefine on the same selector, usually :root.

ONE CONCRETE EXAMPLE The token spacing-section maps small to a smaller value and large to a bigger value. The transform emits the property in :root at the small value and reassigns it inside a min-width media query at the large value. A layout that uses padding var(--spacing-section) gets the small padding on phones and the large padding on desktops automatically, with no media query in the layout's own CSS.