Skip to main content

Search rules

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

designTailwind

Override the dark Variant, Don't Configure It

SHOULD

SHOULD: Use darkMode: "class" for user-controllable themes with light/dark/system options

Redefine the dark variant with @custom-variant so a class can drive the theme, because the darkMode option no longer exists

Bad

Good

Why it matters

The `darkMode: 'class'` config option is gone — there is no config file to put it in. In v4 the `dark` variant is just a variant, and you change its behaviour by redefining it with `@custom-variant`. This repository is its own reference implementation: `src/index.css` line 7 reads `@custom-variant dark (&:is(.dark *));`, which is why toggling `.dark` on `<html>` themes this entire app.

The reason to override at all is unchanged: the default media-query variant reads the OS setting and nothing else, so a user who wants dark on a machine set to light has no way to ask for it and no way to persist the choice. Driving the variant from a class puts the decision in your hands — read `prefers-color-scheme` as the initial default, then let a toggle write `.dark` and store the preference.

Note the selector shape: it must match both the `.dark` element itself and its descendants, otherwise `dark:` utilities on `<html>` never fire.

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.