Forms & Inputs

Everything you've built so far just displays content. A form is different — it's how a page collects something from the person reading it and hands it off somewhere else, or to a script.

The <form> element

A <form> wraps a group of inputs plus a way to submit them. On a real site, its action attribute says where the data goes and method says how (usually get or post). In the sandbox below there's nowhere for the data to actually go, so focus on the inputs themselves — try adding a checkbox of your own:

Try it yourself
Result

Common input types

An <input>'s type attribute decides both how it looks and what the browser lets you type into it:

  • text — a single line of free text.
  • email — a single line, and the browser nudges you to include an @ before submitting.
  • password — text is masked with dots as you type.
  • number — shows up/down arrows and rejects non-numeric characters on most browsers.
  • checkbox — an on/off box; several can be checked at once.
  • radio — one choice out of a group that share the same name.
  • date — a calendar picker in most browsers.
  • file — lets someone pick a file from their device to upload.

Try switching between a couple of these types below:

Try it yourself
Result

Why <label> matters

A <label> tied to an input with matching for/id values does two useful things: clicking the label text focuses (or toggles) the input, and screen readers announce the label when the input receives focus. Skipping labels is one of the most common accessibility mistakes on real sites.

Note: a form on its own doesn't stop bad input — a browser can nudge someone toward filling things in correctly, but the real checking always has to happen again wherever the data ends up. We'll look at the built-in nudging tools in Form Validation.
PreviousTables