Visual Editing for Tailwind CSS v4 — What Changed and Why It Matters

Tailwind CSS v4 is the biggest architectural change since the framework launched. The configuration file is gone — replaced by native CSS directives. The color system moved to oklch. The build pipeline switched from PostCSS to a Rust-based engine. These changes are good for performance and standards alignment, but they broke most visual tools that depended on Tailwind v3's JavaScript-based config.

What Changed in v4

The most visible change is how you configure your design tokens. In v3, you wrote a tailwind.config.js file that exported a JavaScript object. In v4, you define your tokens directly in CSS using the @theme directive. Custom variants use @custom-variant. Utilities use @utility. Everything lives in your stylesheet.

/* Tailwind v4 — CSS-native configuration */
@import "tailwindcss";

@theme {
  --color-brand: oklch(0.65 0.24 275);
  --color-surface: oklch(0.97 0.01 260);
  --font-family-display: "Inter", sans-serif;
  --breakpoint-xs: 475px;
}

@custom-variant dark (&:where(.dark, .dark *));

@utility glass {
  backdrop-filter: blur(12px);
  background: oklch(1 0 0 / 0.6);
}

This is a fundamental shift. The configuration is no longer a separate JavaScript file that needs to be parsed and merged — it is standard CSS that any browser or tool can read. But it also means that any visual builder that was reading tailwind.config.js to understand your design tokens now gets nothing.

Why Visual Builders Broke

Most Tailwind-aware visual tools worked by parsing the JavaScript config, extracting your theme values, and using them to populate color pickers, spacing scales, and font selectors. With v4, that config file does not exist. The tools that depended on it show default values or fail silently.

The CDN also changed. Tailwind v3 used cdn.tailwindcss.com with a script tag. Tailwind v4 uses @tailwindcss/browser from jsDelivr, loaded as an ES module. Visual tools that inject the v3 CDN into preview iframes render v4 projects incorrectly — classes do not resolve, custom tokens are ignored, and the preview looks nothing like the real site.

How Backdraft Handles v4

Backdraft auto-detects which version of Tailwind your project uses by scanning your CSS files for v4 signatures: @theme blocks, @custom-variant directives, @utility rules, and oklch() color values. If any of these are found, Backdraft switches to the v4 CDN automatically. No configuration, no manual toggle.

• Auto-detection of v4 via @theme, @custom-variant, @utility, and oklch() patterns
• CDN switching: v3 projects get cdn.tailwindcss.com, v4 projects get @tailwindcss/browser from jsDelivr
• CSS-native config parsing: @theme values are read directly from your stylesheets
• Dark mode support: the preview iframe respects v4's CSS-native dark mode toggling

The oklch Color Space

Tailwind v4 defaults to oklch for its color palette. oklch is a perceptually uniform color space — meaning that two colors with the same lightness value actually look equally bright to the human eye, unlike HSL. This makes programmatic color manipulation (lighten, darken, adjust saturation) much more predictable.

For visual editing, this matters because tools need to recognize oklch values in your design tokens. Backdraft detects oklch colors and @theme directives to identify v4 projects, and the design system respects oklch color tokens defined in your stylesheets.

What This Means for Your Workflow

If you are migrating to Tailwind v4, or starting a new v4 project, visual editing should not be something you have to give up. The shift to CSS-native configuration is a net positive for the ecosystem — it reduces tooling complexity and aligns with web standards. Visual builders just need to keep up, and the ones that read CSS directly (rather than JavaScript configs) are better positioned for the future.