Tailwind CSS: Why Ignore the Colors?
Using Tailwind CSS with custom properties and HSL to create flexible themes without giving up utility classes.

Tailwind's color utilities are hard to beat for speed. But there is a point, usually dark mode or a client's brand palette, where the built-in colors stop being enough. Here is where that line sits, and what to use instead.
Tailwind's color utilities
A class like bg-persimmon/100 or text-red-600 gets you a wide, consistent color range with no setup. For most projects, the default palette is enough on its own.
The challenge of custom theming
The default palette runs into its limits with dark mode, or with a brand that needs its own specific colors. At that point, the color classes alone are not enough.
CSS variables
Defining primary, secondary, and other core colors as CSS custom properties means the theme can change without touching the markup. Update a handful of variable declarations, and the change propagates through the whole project.
HSL over hex
HSL makes more sense than hex for this. Because hue, saturation, and lightness are separate values, you can adjust one with calc() and generate a consistent set of shades instead of picking each one by eye.
:root {
--primary-color: hsl(210, 80%, 50%);
--secondary-color: hsl(30, 90%, 60%);
}
.dark-mode {
--primary-color: hsl(210, 80%, 30%);
--secondary-color: hsl(30, 90%, 30%);
}
Using both together
Custom theming does not replace Tailwind, it extends it. Tailwind still handles layout and spacing; CSS variables just take over the one part, color, that needs to change at runtime. Reach for the default palette first, and switch to variables only once a project actually needs to.
