HTML Forms Table
| Element / attribute | Purpose | Key attributes |
|---|---|---|
<form> | Container; owns submit and the action/method pair | action, method, novalidate |
<label> | Caption bound to a control - click it to focus | for (must match the control id) |
<input> | The workhorse - type switches its personality | type, name, required, value, placeholder |
<textarea> | Multi-line text | rows, cols, maxlength |
<select> / <option> | Dropdown; option list inside | multiple, size, selected |
<optgroup> | Grouped options inside a select | label |
<datalist> | Suggested values for a text input | id (linked by input list attribute) |
<fieldset> / <legend> | Grouped controls with a caption | disabled (disables the whole group) |
<button> | Clickable action - type switches behavior | type=submit|reset|button |
<output> | Result of a calculation | for (the inputs it reflects) |
<progress> | Task completion bar | value, max |
<meter> | Scalar gauge within a known range | value, min, max, low, high, optimum |
required | Native mandatory validation | Boolean attribute on input/select/textarea |
pattern / minlength / maxlength | Native format and length validation | pattern takes a regex; CSS :invalid styles the state |
HTML forms have quietly become excellent: native validation, accessible grouping, keyboard handling and mobile keyboard hints all ship with the platform - no JavaScript required until you want custom error messages. The table below is the working set: the elements, the validation attributes, and the pairing rules that make them behave.
Bottom line: two rules fix most forms before any code is written. Every input needs a real label - a <label for> bound to the control's id, because placeholder text disappears on the first keystroke and screen readers treat it as a hint, not a name. And every input needs a name attribute - unnamed fields are silently dropped from the submission, which is the classic "the field was there but the email never contained it" bug.
The honest part: native validation runs before your submit handler and it is better than most hand-rolled JavaScript - required, type=email, pattern, minlength all produce browser-localized messages for free. The catch: it only validates what the attributes say, so a type=text field with a pattern is fine, but a custom rule (password strength, username availability) is where JavaScript earns its place.
How to use
- Find the element or attribute in the table - the first column is the exact tag or attribute name to type.
- Check the key-attributes column for the pairing rule: label for matches input id, datalist links by list attribute, output for names its inputs.
- Start native: required, pattern and the right input type cover most validation - add JavaScript only for custom rules and messages.
Frequently asked questions
How does native HTML validation work?
Attributes, not scripts: required rejects empty values, type=email and type=url check format, pattern takes a regular expression, min/max/length bound the value. The browser blocks submission and shows a localized message when a constraint fails - before any JavaScript runs. Style the states with CSS pseudo-classes (:invalid, :valid, :required) and read validity in JS through the element's validity object when you need custom messages.
What is the difference between placeholder and label?
A label is the field's name - always visible, bound with for=id, read aloud by screen readers, click-to-focus. A placeholder is a hint inside the empty field - it disappears on the first keystroke, its contrast is usually too low, and screen readers treat it as supplementary. Replacing labels with placeholders is the most common form accessibility failure; the fix is one line: <label for="email">Email</label> in front of the input.
Why is the name attribute required on form fields?
The submission format is name=value pairs - an input without a name has nothing to submit under, so the browser drops it silently. Everything works on screen and the backend never receives the field, which makes this the most confusing silent failure in HTML. Checkboxes are the special case: an unchecked checkbox submits nothing at all, which is why servers treat its absence as false.
When should a button be type="button"?
The default button type inside a form is submit - a plain <button> in a form sends the form, which surprises everyone exactly once. type="button" opts out of submission for click-handled actions (show a picker, copy text); type="reset" clears the form. The rule of thumb: buttons that save or send data keep the default submit so Enter works; buttons that do something else on the page declare type="button" explicitly.