HTML Form Validation is underused

Original Article ↗ Hacker News Discussion ↗

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.