Unifying Tailwind v4 and Element Plus with a Design Token Bridge
Teams using Element Plus with Tailwind typically fight two separate theming systems that drift apart. Routing both through a single token layer means a color change in one place updates every component and utility class, cutting the maintenance tax of keeping a component library and a utility framework visually in sync.
The approach defines primitive color values in oklch(), wraps them in semantic tokens like `--color-primary`, and then feeds those into Element Plus component variables. Tailwind v4's `@theme` directive registers everything directly in CSS, no JavaScript config needed. Element Plus components automatically inherit the token values when its internal CSS variables are pointed at Tailwind's custom properties. Utility classes can also map back to Element Plus variables, giving developers `text-el-primary` and similar shortcuts. For conflicts, disabling Tailwind's preflight base styles is the recommended fix; a class prefix like `tw:` offers an alternative at the cost of ergonomics.
Element Plus already runs on CSS custom properties, which makes it unusually straightforward to wire into a token system — many component libraries require deeper SASS or LESS variable injection.
Tailwind v4's move to CSS-first configuration with `@theme` removes the need for a JavaScript middleman, so the entire theming pipeline can live in a single stylesheet that both the utility framework and the component library read from.
The recommendation to disable preflight rather than fight it acknowledges that Tailwind's opinionated reset is often the wrong starting point when a mature component library already ships its own sensible defaults.