CSS :user-valid: confirm a checked field without premature praise

When to use it

A reference lookup form requires a case identifier with a constrained pattern. The field starts neutral. Once the browser exposes user-valid, the border shifts to a positive tone; after user-invalid, a separate error style applies. Keep the visible format hint and a real error message after submission, because a border cannot say why a value failed. Test typing part of the identifier, blur, correction, paste, autofill, and resubmission after a server rejection. Browser timing for interaction states can vary, so do not make the positive border the only proof that a field was accepted. The server may reject a syntactically valid identifier because the case does not exist or the viewer lacks access. Keep that result in application text, not in a native validity pseudo-class. A read-only or disabled control follows different validation rules; scope the selector to editable controls in the form. Color must not be the sole state cue, especially in forced colors.

.case-lookup input { border: 2px solid #5e7480; }
.case-lookup input:user-valid { border-color: #1f6b4b; }
.case-lookup input:user-invalid { border-color: #a33b42; }
.case-lookup input:focus-visible { outline: 3px solid #1c5e87; outline-offset: 2px; }

Cost and verification

Selector matching is cheap. The hard part is coordinating native constraints, application messages, and server responses so they do not contradict one another. A browser may expose the state after a committed change or attempted submission, and the visual cue can update while a user edits again. Test that sequence rather than assuming a single fixed blur event. Native constraints validate syntax and required values, not business authorization. Do not paint a valid field as an approved case; the form must report the server's actual result. Keep focus styling distinct from success styling so keyboard users can still locate the active field.

Common Mistakes

• Do not treat :user-valid as server approval.
• Do not use :valid when untouched optional fields should remain neutral.
• Do not rely on green color alone to communicate a result.

Connected lessons

• CSS Property Decisions
• CSS user-invalid: delay visual errors until interaction warrants them
• CSS :required and :optional: reinforce a real form requirement
• CSS form states: make errors and disabled fields explicit
• HTML constraint validation: improve feedback without trusting the browser