20 CSS Form Validation

Bare :invalid matches the moment the page loads. An empty required field is invalid from the very first paint, so a form styled with :invalid renders every field red before the visitor has typed a single character — which reads as broken rather than as helpful. :user-invalid fixes exactly this: it matches only after the user has actually interacted with the field, meaning after they have typed and blurred, or after a submit attempt. The name is the specification being literal — the field is invalid as far as the user's own input is concerned. Support is Chrome 119, Safari 16.5 and Firefox 88, and the classic fallback for older engines is :invalid:not(:placeholder-shown), which approximates the same behaviour by refusing to match while the field is still empty. Declare that rule first and let :user-invalid override it. Demo 01 in this collection shows both side by side so the difference is visible rather than theoretical.

Reserve the space before the message exists. If the error element only appears in the DOM when validation fails, everything below it moves down at exactly the moment the user is trying to read it — and that is a Cumulative Layout Shift event as well as a usability problem. The cleanest modern approach is a grid row that animates from 0fr to 1fr: the message lives in a grid child with overflow: hidden, and the row size transitions between those two values, so it expands smoothly without a magic max-height number that you have to guess and then maintain. Where you can rely on it, interpolate-size: allow-keywords lets you transition to auto directly, though Safari and Firefox have not shipped it, so keep the 0fr path as the base. The blunt alternative that always works is simply giving the message container a fixed min-height sized to one line of text — less elegant, but it never shifts, and for a single-line message it is perfectly reasonable.

Four things, and they work together. Put aria-invalid="true" on the field while it is in an error state and remove it when the field becomes valid — that is what tells assistive technology the control itself is wrong, not just that some red text exists nearby. Link the field to its message with aria-describedby pointing at the message element's id, so the error is read out as part of the field rather than as orphaned text. Put the message after the input in DOM order, because a screen reader announces the description after the label and value, and a message placed before the field can be announced out of sequence. Finally, never signal an error with colour alone — that fails WCAG 1.4.1 for colour-blind users and for anyone in bright sunlight. Every error state in this collection pairs the colour with an icon and with text. If you are announcing errors dynamically rather than on a page load, you also need a live region, and the critical detail there is that the region must already exist in the DOM before you write into it.

After they finish. Validating on every keystroke means the field turns red while someone is halfway through typing their email address, which is both wrong and hostile — the value is not invalid, it is incomplete. The convention that works is to validate on blur for a field the user has already filled, and on submit for everything else. Once a field has been marked invalid, it is reasonable to switch that individual field to live re-validation so the error clears the instant the user fixes it, which feels responsive rather than punishing. :user-invalid gives you the blur-based half of this behaviour for free with no JavaScript at all, which is a large part of why it is worth the browser-support floor. The one case for immediate feedback is a character counter approaching a hard limit, because there the information is genuinely useful before the user finishes — and even then, announce it once at the threshold rather than on every keystroke.

Native HTML cannot express it. The required attribute on a checkbox means that specific box must be checked, which is correct for a single "I accept the terms" control but useless for "pick at least one option". Radio buttons behave differently — there, required on any member applies to the whole group, because a radio group is a single value by definition. For checkboxes you need a small shim, and the right way to write it is with setCustomValidity() rather than a CSS class: pick one member of the group as the carrier, and on every change set a non-empty message on it when nothing is checked and an empty string when something is. Passing an empty string is what clears the error — passing null does not, and that mistake leaves the field permanently invalid, which is one of the more baffling bugs to debug. The payoff is that the state lives inside the browser's own constraint system, so :user-invalid, checkValidity() and the native submit blocking all understand it without any further work.

No, in almost every case. A disabled submit button is a dead end: it gives the user nothing to click and no explanation of what is wrong, so they are left hunting for the offending field with no feedback loop. It is also an accessibility problem, because a disabled element is removed from the tab order and drops focus silently. The better pattern is to leave the button enabled and let the submit attempt do the work — the browser focuses the first invalid field and shows its message, or your handler calls reportValidity() and does the same thing. The user gets a specific answer to "why can't I continue?" instead of a greyed-out rectangle. There is a narrow exception for destructive or irreversible actions where you genuinely want to prevent an accidental activation, but for a signup form, a checkout, or a contact form, an always-enabled button that explains itself on click is both more usable and more accessible.

For styling the states, yes — and that is most of what people actually want. The browser's constraint validation runs regardless of whether you write any JavaScript, so :user-invalid, :user-valid, :placeholder-shown, :required, :out-of-range and friends all match on their own, and :has() lets a parent react to a child's state so you can style a whole field wrapper or reveal a summary panel without a line of script. What CSS cannot do is express a constraint the platform has no attribute for: comparing two fields to each other, checking one value against another field's value, or anything requiring a computed rule such as a Luhn check. Those need setCustomValidity(), which is a handful of lines and keeps the verdict inside the native system. It is also worth knowing what novalidate does and does not turn off — it stops the browser blocking submission and suppresses the built-in bubbles, but the CSS pseudo-classes keep matching, so you can take over the messaging entirely while keeping every state style intact.

The CSS ports unchanged — every .fv-NN selector and custom property is framework-agnostic, and eleven of the twenty demos need no JavaScript at all. The part worth rethinking is that React-era form code often reimplements validation in state, tracking a touched flag per field and a parallel error object, when :user-invalid already encodes "touched and invalid" in the platform. Leaning on the native constraint system means less state to synchronise and fewer ways for the UI to disagree with the actual validity of the form. Where you do need custom rules, call setCustomValidity() in an effect or handler and let the pseudo-classes style the result. Vue and Svelte follow the same shape with a ref or a plain binding. For Tailwind, the state variants map directly — user-invalid: is available as a modifier, so the error styling stays in markup alongside everything else, and the arbitrary-variant syntax covers :has() where you need a parent to react.