Matheion

MA-WEB1 · Module 7

Forms

Topics: form element · input types · Checkbox vs radio · Labels · get vs post

Overview

Session 7 — Forms

You will collect visitor input with the form element and its controls: input (text, email, number, date, password, checkbox, radio), textarea, select, and the submit button. The three pillars: every control has a name (the key the server reads), every control has a label wired by for/id, and get vs post decides whether data travels visibly in the URL or privately in the request body.

Plan: ideas → worked forms → bridge → short drills → reveal.

Time: about 60–70 minutes if you write the name=value pairs for every form before reading the reveal.

Concepts

Session 7 — Forms

The one-paragraph story

Forms are the web's way of asking the visitor for input. A form element wraps a set of controls — text fields, choices, buttons — and decides where the collected data goes. The heart of a control is its name attribute: the browser sends name=value pairs to the server, so a control without a name contributes nothing. Every control gets a label so the visitor (and their screen reader) knows what is being asked. This session builds the Harbor Café's contact and reservation forms, and learns the anatomy of the main controls: input (many types), textarea, select, and the submit button.

The form element

<form action="submit.php" method="post">
  …controls…
</form>

Two attributes decide what happens on submit:

  • action — the URL that receives the form data.
  • method — how the data travels: get appends the data to the URL (visible, fine for simple searches, never for personal data); post sends it in the request body (hidden, right for personal data and changes).

Every form you write contains controls and a way to submit. Without action, the form submits to the current page.

The input element and its types

input is a single element whose type decides what it looks like and what it accepts:

<input type="text" name="name" placeholder="Your name">
<input type="email" name="email">
<input type="tel" name="phone">
<input type="date" name="date">
<input type="number" name="guests" min="1" max="20">

Common types: text, email, tel, number, date, password, checkbox, radio, submit. Each adds behaviour: email warns on an address without an @, number shows steppers and honours min/max, password masks the characters. The name is the attribute the server reads; placeholder is the faint hint text inside the field.

Checkboxes and radio buttons

Choices use two more types:

<p>Dietary notes (pick any that apply):</p>
<input type="checkbox" name="diet" value="vegan" id="diet-vegan">
<label for="diet-vegan">Vegan options</label>
<input type="checkbox" name="diet" value="gf" id="diet-gf">
<label for="diet-gf">Gluten-free options</label>

<p>Seating:</p>
<input type="radio" name="seating" value="inside" id="seat-in">
<label for="seat-in">Inside</label>
<input type="radio" name="seating" value="pier" id="seat-pier">
<label for="seat-pier">On the pier</label>
  • Checkbox — each box is independent; the visitor may pick any subset. Same name, different value.
  • Radio — the same name groups the options into one choice; picking one deselects the others. Exactly one value is submitted for the group.

Both need a value: the browser sends name=value (e.g. seating=pier), so a value-less choice submits an empty string.

textarea and select

Longer text uses textarea; a dropdown list uses select with option children:

<label for="msg">Message</label>
<textarea id="msg" name="message" rows="4">Your message here…</textarea>

<label for="time">Preferred time</label>
<select id="time" name="time">
  <option value="morning">Morning</option>
  <option value="afternoon">Afternoon</option>
  <option value="evening">Evening</option>
</select>
  • textarea is not an input — it has a closing tag and holds its own text; rows/cols hint at its size.
  • select wraps options; the chosen option's value is submitted (or its text if it has no value).

Labels: every control's name tag

A label names its control. Two ways to connect them:

<!-- Wrap the control in the label -->
<label>Your name <input type="text" name="name"></label>

<!-- Or reference the control by id -->
<label for="email">Email</label>
<input type="email" id="email" name="email">

The second form uses for matching the control's id. Labels matter three ways: the visitor sees the question, a screen reader announces it, and clicking the label focuses the control — a bigger click target, especially for tiny radio buttons and checkboxes.

The submit button

<input type="submit" value="Send reservation request">

Or a button element: <button type="submit">Send</button>. The label on the button is what the visitor clicks; the form then packages every named control and sends it to action.

Putting it together: a reservation form

<form action="reserve.php" method="post">
  <label for="res-name">Your name</label>
  <input type="text" id="res-name" name="name">

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

  <label for="res-date">Date</label>
  <input type="date" id="res-date" name="date">

  <label for="res-guests">Guests</label>
  <input type="number" id="res-guests" name="guests" min="1" max="20">

  <button type="submit">Request reservation</button>
</form>

Read it as a pipeline: labels ask the questions, controls collect the answers, the name attributes tag each answer, and the submit button ships the whole name=value bundle to reserve.php via post.

Pitfalls to watch for

  • A control without a name submits nothing — the server has no key for its value.
  • Radio options with different names are separate groups — grouping requires the same name.
  • label without for (or wrapping) is disconnected — clickable, but meaningless to screen readers.
  • get puts data in the URL — never for passwords, addresses, or anything private.

Examples

Session 7 — Worked examples

Example A — A complete contact form, annotated

<form action="contact.php" method="post">
  <label for="c-name">Your name</label>
  <input type="text" id="c-name" name="name">

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

  <label for="c-topic">Topic</label>
  <select id="c-topic" name="topic">
    <option value="catering">Catering</option>
    <option value="press">Press</option>
    <option value="feedback">Feedback</option>
  </select>

  <label for="c-msg">Message</label>
  <textarea id="c-msg" name="message" rows="5"></textarea>

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

Walk the pipeline:

  1. action="contact.php" — where the data goes; method="post" — in the request body, not the URL.
  2. Each label uses for pointing at its control's id.
  3. Each control has a name: name, email, topic, message.
  4. The select has four options; picking "Press" submits topic=press.
  5. The submit button sends everything.

On submit the server receives: name=…, email=…, topic=…, message=….

Example B — What name=value pairs look like

For the form above with method="get", submitting the topic "Feedback" with the message "Great chowder" produces a URL like:

contact.php?name=Ada&email=ada%40example.com&topic=feedback&message=Great+chowder

The name=value pairs appear after the ?, separated by &; special characters get encoded (@ becomes %40, spaces become +). This visibility is why get is fine for a simple search but wrong for personal data — everything the visitor typed is now in the address bar and browser history. With post, those pairs travel in the request body, invisible.

Example C — Checkboxes vs radio in the same form

<p>Choose any dietary accommodations:</p>
<input type="checkbox" name="diet" value="vegan" id="d-vegan">
<label for="d-vegan">Vegan</label>
<input type="checkbox" name="diet" value="gf" id="d-gf">
<label for="d-gf">Gluten-free</label>

<p>Choose one seating area:</p>
<input type="radio" name="seating" value="inside" id="s-in">
<label for="s-in">Inside</label>
<input type="radio" name="seating" value="pier" id="s-pier">
<label for="s-pier">On the pier</label>
  • Both checkboxes share name="diet" but have different values — the visitor may tick both; the server receives diet=vegan&diet=gf or just one.
  • Both radios share name="seating" — picking "On the pier" deselects "Inside"; the server receives exactly one seating=pier.

The rule to remember: radio options with the same name = one choice; checkboxes with the same name = any subset.

Example D — A number field with limits

<label for="guests">Number of guests</label>
<input type="number" id="guests" name="guests" min="1" max="12" step="1">

The browser offers steppers and will complain if the visitor types 0 or 25. Note that min/max are hints the browser enforces on its own — a real site re-checks on the server, because the browser's checks can be bypassed.

Example E — A password field and why name is not the visible label

<label for="pw">Choose a password</label>
<input type="password" id="pw" name="pw">

The label says "Choose a password" to the human; the name="pw" is the machine-readable key sent to the server (pw=secret). They are independent — the label is for people, the name is for the server. Renaming the label never changes what the server receives.

Practice check — forms

Multiple-choice check from the Matheion app lesson. Pick an answer for each question, then submit.

  1. 1.A control with no `name` attribute:

  2. 2.To make three radio buttons one single choice, they must:

  3. 3.A `label for="c-email"` connects to its control when the control has:

  4. 4.A reservation form with the visitor's name, email, and address should use:

  5. 5.In a `select`, the value submitted is: