Skip to main content

Search rules

Search all UI Guides rules by name, category, or source

designTailwind

Custom Breakpoints When Needed

SHOULD

SHOULD: Add custom breakpoints via theme.extend.screens; avoid arbitrary min-[Xpx]: values

Add project-specific breakpoints as --breakpoint-* theme tokens, not as scattered arbitrary min-[…] values

Bad

Good

Why it matters

The v3 answer, `theme.extend.screens`, no longer exists — there is no config object to extend. A breakpoint in v4 is just another theme token: declare `--breakpoint-3xl: 120rem;` inside `@theme` and you get `3xl:` (plus `max-3xl:` and every other variant that keys off it) for free. The rule underneath is unchanged and is the reason this principle exists: a raw `min-[960px]:` is a magic number with no name, so the second person who needs that breakpoint guesses 961 or 959 and the layout now breaks in a one-pixel band.

Name it once, use the name everywhere. Two v4 specifics worth knowing: because breakpoints are ordinary custom properties, they are sorted by value rather than by declaration order, so a new token slots into the right place in the cascade automatically; and `--breakpoint-*: initial;` wipes the built-in scale if you want only your own names.

Built by Gleb Stroganov, design engineer at Evil Martians.

The rules come from other people's skills and guidelines — Vercel, Rauno Freiberg, @Ibelick, impeccable, Emil Kowalski, Tailwind, RAMS — each one credited on the Sources page. The work here is extraction and wiring: every rule is pulled into one corpus, given a good and a bad example you can operate, a MUST/SHOULD/NEVER rule an agent can paste, and a link back to where it came from.