LOG 06 · STYLING
Tailwind CSS v4
Tailwind v4 for fast, consistent layout work — paired with hand-written CSS for the parts (3D stacking, custom shader overlays, keyframe animation) that need pixel-level control a utility class can’t express.
Published · Updated
Utilities for structure, CSS for craft
Tailwind handles the parts of a layout that are genuinely repetitive — spacing scales, flex/grid structure, responsive breakpoints — fast, and without inventing a new class name for every div. But the parts of a site that make it feel custom rather than templated (a specific oklch color ramp, a z-index choreography between a WebGL canvas and a CSS3D layer, a hand-tuned keyframe animation) are still hand-written CSS, because that's where a utility class stops being faster than just writing the three lines of CSS directly.
Tailwind v4's CSS-first configuration — real `@theme` custom properties instead of a JS config object — makes that split easier to maintain: the same design tokens (color, spacing) are addressable from both the utility classes and the hand-written CSS sitting right next to them.
Where the utility layer stops
The split shows up clearly in practice. Page rhythm — stack direction, gaps, breakpoints, max widths — is utilities, because those are the decisions that repeat on every page and benefit from a shared scale. Everything with a specific identity is a real class in one stylesheet: the heading rhythm the journal and case-study pages share, the accent-coloured counters on a numbered list, the hairline rules that separate one block of a page from the next.
Colour is the clearest example of why that split works. The palette is written in oklch rather than hex, because perceptual lightness is the thing being tuned when a muted body colour has to sit a precise distance below a heading on a near-black background. Those values live as custom properties, which means the utility classes and the hand-written rules are reading from the same tokens instead of drifting apart.