Forms

A <form> declares an interactive region whose controls submit data to a server endpoint or participate in client scripts.

Core attributes

• action: URL accepting submissions (defaults to current document).
• method: get (idempotent queries, bookmarkable) vs post (body payloads, mutations).
• enctype: defaults to application/x-www-form-urlencoded; switch to multipart/form-data for file inputs.
• autocomplete: hints for browser password managers and form fillers.
• novalidate: disables native constraint validation when you supply bespoke validation UX.
• target: opens responses in new browsing contexts—pair carefully with security (rel on submit buttons).

<form action="/search" method="get" role="search">
  <label for="q">Search</label>
  <input id="q" name="q" type="search" autocomplete="off">
  <button type="submit">Search</button>
</form>

Rendered output

GET vs POST

• GET appends name=value pairs to the query string—subject to length limits and logging.
• POST sends fields in the request body—appropriate for large payloads, file uploads, or sensitive data (still require HTTPS).

Security baseline

• Generate CSRF tokens server-side for authenticated mutations.
• Validate every field again on the server—never trust client-side checks alone.
• Use appropriate autocomplete tokens for credentials and PII handling.

What even senior teams forget

• Method semantics: GET requests should be safe/idempotent—don’t mutate databases on GET even if bots can hit URLs.
• CSRF aside: samesite cookies help but do not replace explicit tokens when requirements demand defense in depth.
• Autocomplete off isn’t privacy: it frustrates legitimate password managers—use precise tokens (one-time-code, billing scopes) rather than blasting autocomplete="off" everywhere.
• multipart boundaries: missing enctype on file uploads silently drops binaries—classic production support ticket starter.

Submission UX realities

• Disable submit while in-flight—but re-enable on network errors so users retry.
• Preserve scroll position after server validation errors—jumping users to tops of long forms feels broken.
• Double submits: optimistic UI ≠ duplicate charges—idempotency keys belong server-side.

Accessibility test script (forms)

Important interview questions and answers

1. Q: Why are native form controls preferred over custom div-based widgets?
   A: They provide built-in semantics, keyboard support, validation hooks, and accessibility behavior.
2. Q: What does `name` do on form fields?
   A: It determines the key sent in form submission payloads; without `name`, values are typically not submitted.
3. Q: When should you use `type="button"` instead of default buttons in forms?
   A: Use `type="button"` for non-submit actions to avoid accidental form submission.