Radius Token Scale

Quick implementation

:root {
  --radius-none: 0;
  --radius-sm:   0.25rem;
  --radius-md:   0.5rem;
  --radius-lg:   0.75rem;
  --radius-xl:   1rem;
  --radius-2xl:  1.5rem;
  --radius-3xl:  2rem;
  --radius-full: 9999px;
}

/* Usage */
.button  { border-radius: var(--radius-md); }
.card    { border-radius: var(--radius-lg); }
.pill    { border-radius: var(--radius-full); }
.input   { border-radius: var(--radius-sm); }

Prompt this to your LLM

Includes role, constraints, two framework variants, and edge cases to handle.

You are a CSS design systems engineer. Create a border-radius token scale using CSS custom properties.

Requirements:
1. Define --radius-none (0) through --radius-full (9999px) with 6–8 steps.
2. Use a consistent progression: 0, 0.25rem, 0.5rem, 0.75rem, 1rem, 1.5rem, 2rem, 9999px.
3. Apply tokens to common components: button (--radius-md), card (--radius-lg), pill badge (--radius-full), input (--radius-sm).
4. Show a visual demo: a row of squares each with a different radius and labeled with the token name.

Framework variants:
A) CSS-only with :root custom properties.
B) Tailwind config extension — add the scale to theme.borderRadius in tailwind.config.js.

Edge cases:
- --radius-full (9999px) works reliably for pill shapes regardless of element height.
- For nested rounded elements, use calc(var(--radius-lg) - 4px) on inner elements to maintain optical alignment.
- Document that border-radius clips content — pair with overflow: hidden if needed.

Why this matters in 2026

Inconsistent border-radius values are one of the most common sources of visual noise in component libraries — buttons rounded to 4px in one place and 6px in another create subtle but noticeable incoherence. A token scale turns rounding into a deliberate design decision rather than an ad-hoc guess. Changing the entire product's "roundness personality" then requires editing a single token rather than hunting through hundreds of component files.

The logic

The scale uses a roughly doubling progression from --radius-sm to --radius-3xl, with --radius-full as a semantic token meaning "always fully rounded" regardless of element size. Using 9999px rather than 50% for pills is intentional — 50% creates an ellipse on wide elements, while 9999px clamps to a true semicircle on each end. The tokens compose naturally: nested elements can reference calc(var(--radius-lg) - 4px) to maintain optical alignment with their parent.

Accessibility & performance

Border-radius has no direct accessibility implications but contributes to visual clarity — rounder shapes tend to read as interactive (buttons, pills) while sharper corners suggest structure (cards, panels). There is no performance cost to border-radius on non-animated elements; on animated or scrolling elements, adding overflow: hidden triggers a stacking context that the browser composites on the GPU. Custom properties resolve at paint time with negligible overhead.