HTML Form Controls: input vs textarea vs select

Do not choose a form control only by its appearance. Decide whether the user should send one value, a longer explanation, or one of a fixed set of options. The HTML control shapes the input experience; the server decides whether the submitted data is acceptable.

input: behavior depends on its type

Text-like input types suit short values. The same element also creates checkboxes, radio buttons, and file pickers, so not every input is a single-line text box.

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

The label's for attribute matches the control's id. A placeholder does not replace a persistent visible label. The name attribute provides the field key in a normal form submission; an id alone does not define that submitted key.

textarea: free-form text across multiple lines

<label for="message">Message</label>
<textarea id="message" name="message" rows="5" maxlength="2000"></textarea>

Initial textarea content belongs between the opening and closing tags, not in a value attribute. When inserting stored user text on the server, escape it for the HTML context. The rows attribute suggests a visible height; it does not limit the number of lines a user may enter.

select: choose from allowed values

<label for="topic">Topic</label>
<select id="topic" name="topic" required>
  <option value="">Choose a topic</option>
  <option value="support">Technical support</option>
  <option value="billing">Billing</option>
</select>

The browser submits the selected option's value rather than its visible label. Reject values other than support and billing on the server. A modified client can submit an option that the page never displayed. Multiple selections require a different data shape; also reject an array when your handler expects a scalar value.

Browser validation is not server validation

required and type=email provide early feedback. They do not replace authentication, CSRF protection, or server-side type and length checks. Accepting an email's syntax does not prove that the mailbox exists or belongs to the person submitting it.

Test the form with empty fields and unexpectedly long values. Inspect field names and values in the network request. Remember that disabled controls do not participate in a normal submission. Finally, submit an invalid option directly to the server and verify rejection; seeing a browser warning is not enough.

Reference: MDN form validation guide.