Responsive design tokens in Shilpi: one system for every screen

Responsive design becomes difficult when every section carries its own slightly different spacing and typography rules. Shilpi solves that problem at the system level: a design token can hold desktop, tablet and mobile values, and every class that uses it responds together.

Start with decisions, not individual elements

A token is a named design decision. Instead of giving ten sections ten separate horizontal padding values, define one variable such as --pad-x. Global classes reference that variable, so changing its mobile value updates the whole site without a search-and-replace operation.

Use a small, useful token set

• Colour: background, surface, text, muted text and accent.
• Spacing: page padding, section rhythm and component gaps.
• Typography: body size, display size and readable line height.
• Layout: content width, wide canvas and border radius.

The goal is not to turn every number into a variable. Promote values that carry meaning across multiple components. Keep one-off adjustments close to the page.

Let classes consume the tokens

Global classes are where tokens become a visual system. A card class can use the surface, border, radius and spacing tokens. A heading class can use the heading family and responsive type scale. The canvas remains visual, but the decisions behind it stay consistent.

Test the transitions, not only the endpoints

Preview desktop, tablet and mobile in the Shilpi canvas, then drag through the widths between them. Look for awkward wrapping, crowded controls and images that lose their subject. A responsive system succeeds when the layout remains calm between named breakpoints.

With a disciplined token set, responsive changes stop being a cleanup phase. They become part of the design language from the first section onward.