HTML Form Validation is underused

Boolean attributes & HTML vs JSX

• Several comments clarify that required, disabled, etc. are boolean HTML attributes: presence means true, absence means false. Values like "true"/"false" are technically invalid in HTML (though browsers treat any value as true).
• Examples in the article use required={true}, which is JSX, not HTML. Some find this confusing in an article ostensibly about HTML.
• In JSX, explicitly writing {true} is optional; some prefer it for readability, others see it as noise.

Power and pitfalls of HTML validation

• Built‑in validation (required, pattern, min/max, etc.) is praised for:
  • Immediate feedback.
  • Localized default messages.
  • Automatic focusing of the first invalid field.
  • Simple CSS hooks (:invalid, :user-invalid, :required).
• Many highlight misuses: overly strict regexes (e.g., word-count patterns, password rules), incorrect email/URL assumptions, and confusing error states.
• Some argue pattern and friends handle only basic cases; custom business rules and cross-field checks quickly require JavaScript.

Client‑side vs server‑side validation & duplication

• Consensus: client‑side validation is a UX aid; server‑side validation is still mandatory for security and correctness.
• Pain point: rules often must be implemented twice, in different languages. This can drift and cause bugs or exploits.
• Proposed mitigations:
  • Shared schemas (e.g., JSON Schema, Zod/Valibot) reused on front and back ends.
  • JS‑everywhere stacks (Next.js, Remix, TypeScript) to share types and validators.
  • HTMX‑style server-driven “inline” validation to keep rules server‑only but still responsive.

UX concerns: when and how validation fires

• Default behavior (marking fields invalid on page load) is widely criticized as hostile; many prefer “touched”/on‑submit semantics.
• Some call browser tooltips intrusive; others prefer persistent inline messages under fields.
• maxlength and live character rejection are seen as problematic for copy‑paste and editing; several recommend allowing free input and validating on blur/submit instead.

Input types, mobile keyboards, and weak controls

• Big win: correct type/inputmode values (email, number, url, inputmode=numeric/email) improve mobile keyboards and password manager behavior.
• But native type=number is viewed as inconsistent and awkward (spinners, locale issues, dropping leading zeros); many use type=text + inputmode=numeric instead.
• Native date/time controls are often called “terrible” or inconsistent across browsers and platforms, leading to widespread use of JS date pickers despite accessibility concerns.

Accessibility and styling limitations

• Native validation bubbles are hard or impossible to style consistently; some frameworks/audits require custom validation UI instead.
• Accessibility specialists in one audit recommended abandoning native validation because:
  • Only one error string per field is supported, encouraging concatenated messages.
  • Browser popups are modal, hard to navigate with assistive tech, and can’t show all errors at once.
  • Custom widgets plus hidden inputs complicate semantics.
• Others counter that built‑in semantics and ARIA support are strong arguments for using native controls, provided you layer your own message rendering over input.validity.

Browser inconsistencies

• Firefox for Android reportedly runs constraint validation but fails to show messages at all, causing confusing UX.
• Date/time pickers, number inputs, and some validation behaviors differ notably between browsers and OSes.
• Some argue this is exactly why browsers should improve built‑ins; others say inconsistency and limitations justify full custom implementations.

Frameworks, libraries, and broader philosophy

• Many prefer form libraries (Formik, React Hook Form, TanStack Form) plus schema validators (Zod, Valibot) for richer, centralized validation.
• Some believe browsers should act as low-level UI toolkits and stop adding “half‑baked” high‑level features like validation, leaving complex UX to app code.
• Others argue the opposite: most sites do worse than browsers at accessibility and edge cases, so improving and using native form features would benefit the majority of users.