Signup Form with Validation — HTML CSS JS Snippet

The signup form is the highest-stakes form on any product: every validation annoyance, unclear error, or premature red border costs real conversions. This snippet is a complete registration flow in vanilla HTML, CSS, and JavaScript that implements the patterns conversion research actually supports — blur-triggered validation that turns live only after a field has erred, a five-level password strength meter, show/hide password, a terms checkbox, a loading submit button, social sign-up buttons, and an animated "check your inbox" success overlay.

The validation timing that doesn't fight the user

When to show errors is the defining UX decision of any form, and this snippet implements the researched best practice known as *reward early, punish late*. Each field validates on blur — never while the user is still typing their email for the first time, which is why naive on-input validation feels hostile (you're told "invalid email" after typing one character). But once a field has erred, it flips into live mode: the touched map records that the field has been validated, and subsequent input events re-validate immediately — so the moment the user fixes the mistake, the red border and message vanish, rewarding the correction without waiting for another blur. Valid fields get a subtle green border only when non-empty. On submit, every field is force-touched and validated, and focus moves to the *first* failing input — the accessibility affordance most forms omit.

Validators as data, errors as paired elements

Validation logic is a plain object mapping field names to functions returning an error string or empty — adding a field means one entry and one markup block, no restructuring. Each field's error lives in a .su-error[data-for] paragraph that shows with a small drop-in animation; state classes (invalid/valid) live on the input and drive the border and focus-ring colours. The email regex is deliberately pragmatic (something@something.tld) — exhaustive RFC 5322 regexes reject real addresses and the confirmation email is the true validator anyway, which is exactly what the success screen communicates.

The strength meter: score, don't gatekeep

scorePassword() awards points for length ≥8, length ≥12, mixed case, digits, and symbols, mapping to five meter levels — width, colour (red→orange→yellow→lime→green), and an instructive label ("Weak — add numbers or symbols") that tells users *how* to improve rather than just judging them. Critically, the meter is advisory: only the 8-character minimum blocks submission. Hard composition rules (mandatory symbol + uppercase + digit) are an outdated NIST anti-pattern that produces "Password1!" — length-weighted scoring with guidance produces genuinely stronger passwords. The bar animates via width/background transitions; the show/hide toggle swaps input.type between password and text while updating its aria-label.

Submit, loading, and the success overlay

Submission disables the button, swaps its label to "Creating account…", and reveals a CSS border-spinner — the loading treatment that prevents double-submits without layout shift, since the spinner slots into the existing flex gap. The simulated API resolves into a success overlay: absolutely positioned over the whole card (the form's overflow: hidden keeps its rounded corners), fading in with a spring-popped green ring and echoing the submitted email in "We sent a confirmation link to…" — confirmation-email UX that closes the loop and tells users the next action. Social buttons (Google's official four-colour mark, GitHub's octocat path) sit under an ::before/::after line divider, and autocomplete attributes (name, email, new-password) are set so password managers behave — new-password specifically triggers suggested-password generation in Chrome and Safari.