HTML Forms and Input Types: action, method, labels, select, textarea and button

An HTML form is a <form> element that gathers what a user types and sends it somewhere. The action attribute says where the data goes, and the method attribute says how it gets there — get (the default) appends the data to the URL as a query string, while post puts it in the request body. Everything inside the form — <input>, <select>, <textarea>, <button> — is a control, and each control needs a name attribute or its value never leaves the page.

action, method, and enctype

The action attribute holds the URL that processes the submission. Omit it and the data is sent to the URL of the page containing the form. The method attribute accepts three values: get, post, and dialog — that last one closes a surrounding <dialog> and fires a submit event instead of sending anything. With get, the browser builds a query string such as search.php?q=html&sort=new and sends an empty request body. That is fine for a search you want to bookmark or share, and genuinely bad for a password, because the value sits in the address bar, in browser history, and in server logs. With post, the data travels in the request body instead, which is what you want for anything private, anything large, and anything that changes data on the server. One more attribute matters as soon as you accept files: enctype controls how a post body is encoded. It defaults to application/x-www-form-urlencoded, and it must be set to multipart/form-data when the form contains a file input.

Why every control needs a name

Form data is a list of name=value pairs. The browser walks the form, reads each control's name and current value, and sends the pairs. A control with no name is silently skipped — so is a disabled control, and so is an unchecked checkbox or radio button. This is where name and id get tangled: name is for the server, while id is for the page, used by CSS, by JavaScript, and by a label's for attribute. Radio buttons are a special case: sharing one name across several radios is exactly what makes them mutually exclusive.

Picking an input type

The type attribute on <input> changes both the control you see and the rules the browser enforces. The full set is text, password, email, tel, url, search, number, range, date, time, datetime-local, month, week, color, file, checkbox, radio, hidden, submit, reset, button, and image. Choosing well buys you built-in validation — a value with no @ in an email field blocks submission and shows a browser message — and a better mobile keyboard. If you misspell the type or leave it off entirely, the browser quietly uses text instead.

Labels, select, textarea, and button

A <label>'s for attribute must match the control's id, not its name. That pairing lets a screen reader announce the label when focus lands on the field, and it makes the label text a clickable target. A <select> wraps <option> elements; each option's value is what gets submitted, an option with no value submits its own text content instead, and adding multiple lets the user pick several. A <textarea> takes its starting text from between its tags, because HTML gives it no value attribute at all. And a <button> associated with a form defaults to type="submit" — a detail worth remembering. Ready to practice? Try the D276 practice sets or review the full Web Development Foundations study guide.

A worked example

Here is a small form that uses each piece correctly. Read it once, then read the notes underneath.

<form action="/contact" method="post">
  <label for="name">Full name</label>
  <input type="text" id="name" name="name" required>

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

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

  <label for="msg">Message</label>
  <textarea id="msg" name="message" rows="6"></textarea>

  <button type="submit">Send</button>
</form>

Every control has a name for the server and an id for its label. The first option carries value="", which makes it a placeholder: because it is selected by default and its value is empty, required on the <select> forces the user to make a real choice. The textarea is empty because there is nothing between its tags, and rows="6" overrides the default of 2 rows — writing value="" on a textarea would do nothing at all, since that attribute does not exist for it in HTML.

Mistakes people actually make

• Pointing for at the name. If for="email" but the input's id is user-email, the label is decorative: clicking it does not focus the field and assistive tech reports an unlabeled input.
• Using placeholder as the label. Placeholder text vanishes the moment someone types, leaving them with no idea what the field wanted. Keep a real <label> and treat the placeholder as an example value.
• Giving radio buttons different names. Radios form one mutually exclusive group only when they share a name. With different names each radio is its own group, so several can end up checked at once and clicking one never clears another.
• Forgetting value on checkboxes and radios. With no value, a checked control submits the literal string on — technically valid, practically useless.
• Uploading without enctype. A file input inside a plain post form sends only the file's name, because the default urlencoded format cannot carry binary content.
• Assuming a bare <button> is inert. It submits. Add type="button" to anything that should not.

Reasoning through the tricky cases

When you are unsure whether a value will be submitted, ask three questions in order: does the control have a name, is it enabled, and does it have a value to report? That sequence explains most surprises. It clarifies why readonly and disabled behave differently — a readonly text field or textarea cannot be edited but is still submitted, while a disabled control is excluded from the data entirely and cannot take focus. It explains why an unchecked checkbox produces no pair at all rather than an empty one, and why a whole radio group disappears from the data when nothing is selected. For the exact attribute lists, the MDN reference for <input> is the source worth bookmarking.