Form elements

Beyond standalone <input>s, HTML ships richer controls: multi-line text, enumerated menus, autosuggest lists, progress indicators, and computed readouts.

Element tour

textarea

Free-form multi-line prose; honours rows, cols, wrap, lengths.

select

Drop-down / list-box via size + multiple.

option / optgroup

Choices and labelled groups inside select.

datalist

Native suggestions layered on textual inputs.

progress

Completion of known or indeterminate tasks.

meter

Scalar gauge with low/high/optimum bands.

output

Live result tied via for to other IDs.

fieldset / legend

Groups controls with captions (especially radios).

label

Expands tap target & names control for accessibility.

Example — textarea

<label for="msg">Message</label>
<textarea id="msg" name="msg" rows="4" maxlength="280" placeholder="Say something…"></textarea>

Rendered output

Example — select, option, optgroup

<label for="tz">Timezone</label>
<select id="tz" name="tz" required>
  <option value="">Choose…</option>
  <optgroup label="Americas">
    <option>Chicago</option>
    <option>Denver</option>
  </optgroup>
  <optgroup label="Europe">
    <option>Paris</option>
  </optgroup>
</select>

Rendered output

Huge enumerations strain SR users—virtualize searchable patterns (datalist, combobox libs) instead of 5k-option selects.

Example — datalist

<label for="airport">Airport</label>
<input id="airport" name="code" list="iata">
<datalist id="iata">
  <option value="LHR">London Heathrow</option>
  <option value="ORY">Paris Orly</option>
</datalist>

Rendered output — type freely or pick suggestion

Example — progress

<label>Upload<progress max="100" value="72">72%</progress></label>
<p><progress>Spinning fallback…</progress> Unknown duration</p>

Rendered output

Example — meter

<label>CPU load <meter min="0" max="100" low="70" high="90" optimum="45" value="82">82%</meter></label>

Rendered output

Example — output (for references)

<form>
  <input id="qty" type="number" value="4">
  <output for="qty" name="doubled">8</output>
</form>
<!-- Typical apps recompute outputs with scripts -->

Rendered output (placeholder text—wire JS to update dynamically)

Labels (explicit pairing)

<label for="email">Email</label>
<input id="email" name="email" type="email">

Implicit labels wrapping inputs are legal too—explicit for/id keeps CSS Grid layouts simpler.

Rendered output

Surprising gotchas

• name vs id: only name participates in submission payloads; missing name drops fields quietly.
• Disabled vs readonly: disabled fields aren’t submitted—if you still need values (e.g. tokens), readonly + hidden patterns differ.
• Custom selects: when replacing <select> visually, rebuilding keyboard/typeahead behavior is non-trivial—native first.
• datalist quirks: suggestions differ per browser pairing—still provide manual entry UX.

Grouped inputs

fieldset/legend isn’t cosmetic—radios spanning multiple unrelated questions confuse SR users when only CSS grouped them visually.

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.

Tip: Group related fields with fieldset and legend.