ClaudeHowSupport Us

Common CSS mistakes Claude still makes

Fixed dimensions on content that isn't fixed-length

A recurring pattern is a hardcoded height or width applied to a container holding content whose length genuinely varies — a card, a button, a text label — which works fine against whatever example content was used during generation and breaks the moment real content is longer or shorter than that example. The fix is almost always sizing based on content with sensible minimum or maximum bounds rather than a fixed dimension, but this requires deliberately testing with content that's actually different in length from what was originally used, since the fixed-dimension version looks completely correct against its original test case.

Z-index values chosen without a system behind them

Stacking order handled with arbitrary, increasingly large z-index values — one component at a value, the next one that needs to sit above it at an even higher arbitrary value — tends to work until a third component needs to sit between the first two, at which point the whole ad hoc sequence needs renumbering. A small, deliberate scale of z-index tiers, established once and referenced consistently, avoids this escalating pattern and makes stacking order predictable rather than accumulated through trial and error across unrelated components.

Specificity fights resolved by adding more specificity

A style that isn't applying as expected sometimes gets "fixed" by adding a more specific selector or an !important to force it to win, rather than by understanding why the conflicting rule had priority in the first place. This resolves the immediate symptom but adds another layer to an already-tangled specificity problem, and the next conflict in the same area is now harder to resolve because there's an extra forced override to work around as well. Understanding and fixing the actual source of the conflict, rather than out-specificity-ing it, keeps the problem from compounding.

Flexbox and grid used interchangeably without a clear reason

Both layout systems can often produce a similar visual result for a simple case, which leads to inconsistent choice between them across a codebase — one component using flexbox, a visually similar one using grid, for no reason grounded in what either layout actually needs structurally. This isn't wrong in the sense that either breaks, but it makes a codebase harder to reason about consistently, and it's worth establishing which layout system is the default choice for which kind of structure, then applying that consistently rather than letting it vary component to component.

Media queries added reactively rather than planned around real breakpoints

A responsive fix applied at whatever specific width happened to look broken during testing produces a scattered set of narrow, workaround-shaped breakpoints rather than a small, deliberate set that reflects actual meaningful layout transitions. Over several rounds of reactive fixes, this produces a stylesheet with breakpoints that don't correspond to any coherent design decision, just to whichever specific widths happened to break during whatever testing occurred. Establishing a small, intentional set of breakpoints upfront, and fitting fixes into that existing structure rather than adding new ad hoc ones each time, keeps this from accumulating.

Animation and transition values copied without considering context

A transition duration or easing curve that felt right for one interaction sometimes gets reused for a completely different one — a value tuned for a subtle hover effect applied unchanged to a much larger element entering or leaving the screen, where the same timing feels wrong at a different scale of motion. Treat animation timing as something to tune per interaction rather than a single value copied everywhere it's needed, since what reads as smooth for a small, local change often reads as sluggish or abrupt for a larger one.

See iterating on CSS with Claude without losing the thread for the broader review and iteration discipline that catches these patterns before they compound across a codebase.

Verified 2026-08-08 against ClaudeHow facts module (src/data/facts/) — see /about/#accuracy.