Forms
The platform's oldest interactive component: input types, native validation, submission, focus order, labels — and what you inherit for free before any framework state exists.
A `<form>` ships with submit-on-Enter, validation, autofill, password-manager integration and a label/control relationship. Most custom forms are a worse reimplementation of it.
The right `type`, `inputmode` and `autocomplete` change the on-screen keyboard, the autofill offer and the validation the browser runs — a large UX win for one attribute.
The Constraint Validation API gives you checks, states and messages for free — then runs out at styling, wording and timing. Replacing it means re-implementing what it did well.
Either your framework owns every keystroke or the DOM does and you read at submit. A real trade-off between per-keystroke render cost and reactive capability — not a rule.
GET versus POST is a semantic choice with cache and history consequences; `FormData` and `enctype` decide what goes on the wire; and preventing the second submit is your job.
An error must be programmatically tied to its field, announced when it appears, reachable by focus and expressed in more than colour. Red text is not an error state.