Choosing, not typing

The problem with free text

The previous course gave your forms text boxes, and text boxes have a weakness you will fight for your whole career: people type anything into them. Ask for a country and you'll receive "Brazil", "brasil", "BR", "Brasil 🇧🇷", and "brazl". Ask "do you accept the terms?" and a text box invites an essay. Your Rails controller then inherits the mess, trying to normalize five spellings into one database value.

Selection controls flip the deal. Instead of asking the visitor to produce a value, the page offers values and the visitor picks. The data that reaches your server can only be one of the options you defined. No typos, no creative spelling, no normalization code.

The three shapes of choice

Every selection UI on the web, from a cookie consent banner to an airline seat map, is built from three controls, and each one answers a different question:

The split is about cardinality: how many options exist, and how many the visitor may pick. Zero-or-more from a visible list is a checkbox group. One from a short visible list is radio buttons. One from a long list that would swallow the page is a <select> dropdown.

flowchart TB
  A{"How many may they pick?"} -->|"zero or more"| B["Checkboxes"]
  A -->|"exactly one"| C{"How many options?"}
  C -->|"a few, 2 to 5, worth seeing side by side"| D["Radio buttons"]
  C -->|"many, countries or categories"| E["Select menu"]

Interface designers hold this tree in their heads. So do good Rails developers, because the wrong control produces the wrong data shape: a "pick one" question rendered as checkboxes lets users pick three, and now your controller has to reject input that honest users could enter in good faith.

Same machinery underneath

Here's the reassuring part: everything from the Inputs course still applies. Each of these controls lives inside a <form>, carries a name, and submits a name=value pair when the form is sent. The request line, the query string, the params hash in Rails, none of that changes. What changes is where the value comes from: not from keystrokes, but from an attribute you wrote in the HTML.

<form action="/preferences" method="post">
  <input type="checkbox" name="newsletter" value="yes">
  <button type="submit">Save</button>
</form>

That checkbox will never submit "yse" or "YES!" or a paragraph about newsletters. It submits newsletter=yes or nothing at all. You, the author, wrote the only value it can ever send. That authorship is the theme of this whole course.

Constraint is a gift to your future self

In a few phases you will write Rails models with enum :status and database columns that allow only certain values. Selection controls are the front-end half of that same discipline: the form offers the legal values, the model enforces them, and the database stores them. When all three layers agree on the list, bugs have nowhere to live. When the form is a free-text box and the model expects an enum, users see validation errors that a dropdown would have made impossible.

One warning before we begin, and it matters enough to repeat later: the browser-side constraint is a convenience, not a defense. Anyone can open DevTools, edit your HTML, and submit a value you never offered. Rails validations remain the real gate. Selection controls make honest input clean; they do not make dishonest input impossible.

What this course covers

1. Choosing, Not Typing: why constrained input beats free text (you are here)
2. Checkbox: The On/Off Switch: one box, one boolean, and a famous gotcha
3. Checkbox Groups: many boxes, one question, arrays in params
4. Radio Buttons: pick one of a few, enforced by the browser
5. select and option: dropdowns, and the difference between label and value
6. Grouped, Multiple, and Suggested: optgroup, multiple, and datalist
7. Putting It Together: one preferences form using every control

By the end you'll build the "settings page" shape of form, the one where nothing is typed and everything is chosen, and you'll know precisely what each click sends to the server.