HTML Select

Previously, textarea collected free multi-line paragraphs between its tags. Select is a different job: the user picks one answer from a fixed list — country, plan, size — instead of inventing text. A dropdown (or list box) keeps submissions consistent and easier to validate than open typing.

Why select exists

Shipping forms, meal pickers, and settings screens need a closed set of answers. Typing “Tehran” vs “tehran ” creates messy data; choosing teh from a list does not. <select> holds the control; each <option> is one choice. The control still wants a visible label and a name on the select so the chosen value posts with the form.

Direct answer

1) Write <select id="city" name="city">…</select> with nested <option value="…">Label</option> children.
2) Connect a <label for="city">…</label> (or wrap the control).
3) Put name on the select; put value on each option (visible text is only the fallback if value is omitted).
4) Optional: a first empty value="" prompt (“Choose…”) so nothing meaningful submits until the user picks; selected on a default; disabled on a blocked choice; <optgroup label="…"> for sections.
5) This is list picking — not the previous lesson’s free-form textarea paragraphs.

📊 Select pieces beginners use

Piece	Role	Beginner tip
select	Choice container	Owns name= for the submitted field key
option	One choice	value= is what posts; text is what users see
optgroup	Section header	Groups options; not itself submitted
name (on select)	Submit key	Required if the choice should post
id (on select)	Label hook	Match label for=
value (on option)	Submitted token	Prefer short stable codes (teh, salad)
selected	Default pick	At most one in a single-select list
disabled (option)	Unavailable	Shown but not choosable

Shipping form: labeled city select

A short shipping snippet keeps address notes as a single-line input and the city as a select. A blank “Choose…” option sits first so the user must pick deliberately. Stable value codes (teh, isf) submit instead of display spelling.

Labeled city select

html

<form action="/ship" method="post">
<label for="city">City</label>
<select id="city" name="city" required>
<option value="">Choose…</option>
<option value="teh">Tehran</option>
<option value="isf">Isfahan</option>
<option value="shir">Shiraz</option>
</select>

<label for="note">Delivery note</label>
<input id="note" name="note" type="text" placeholder="Gate code, floor…">

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

Reading the city demo

select (not textarea) is the list control
id="city" pairs with label for="city"
name="city" keys the submitted choice
Each option has a short value; users see the city name
First value="" prompt avoids an accidental default city
required blocks submit until a real city is chosen
Previous-lesson textarea is unused here — the note is a single-line input

Grouped meals with optgroup

A second demo shows a meal picker with <optgroup> sections. Related options sit under Veg or Other so a longer menu stays scannable. selected marks a sensible default when a prompt is not needed.

Meal select with optgroup

html

<label for="meal">Meal</label>
<select id="meal" name="meal">
<optgroup label="Veg">
<option value="salad">Salad</option>
<option value="soup" selected>Soup</option>
</optgroup>
<optgroup label="Other">
<option value="stew">Stew</option>
<option value="grill" disabled>Grill (sold out)</option>
</optgroup>
</select>

Reading the meal demo

optgroup label="Veg" titles a section; it is not a submitted value
Options nest inside the group; value still posts from the chosen option
selected on Soup pre-picks that meal
disabled on Grill keeps it visible but not choosable
Same rules: label + name on the select
Next lesson covers <datalist> for suggesting values while still allowing typed text — different from a closed select

Choosing select vs textarea vs input

One known choice from a list (city, plan, size): <select> + <option>
Free paragraphs / comments: <textarea> (previous lesson)
One short typed line (name, note): <input type="text|…">
Submit key → name on select; payload token → value on option
Still wire a label
Prefer stable codes in value, human labels in the option text
Do not paste a list of choices into a textarea and hope users type exactly

Practice — build and group

Copy the city demo; add a fourth city with a short value code.
Change the prompt text but keep value="" on the first option.
Remove required once, submit mentally with “Choose…” still selected — then restore required.
Build the meal optgroup demo; move Soup into Other and confirm grouping still works.
Mark Grill disabled, then temporarily remove disabled and pick it.
Write one sentence: select posts an option’s value; textarea posts free text between its tags.
Peek ahead: typed suggestions with a free text field belong in <datalist> next — not a closed select alone.

Easy mistakes

Omitting value so the visible label submits when you meant a code
Forgetting name on the select so nothing posts
Skipping a label (a prompt option is not a full accessible name)
Dumping choices into a textarea instead of real options
Huge flat lists with no optgroup when sections would help
Putting name on every option instead of once on the select
Confusing this closed list with next lesson’s <datalist> (suggestions + typing)

Summary

<select> + <option> = pick from a list
Label the select; give it a name for submit
Each option’s value is what posts
Optional prompt, selected, disabled, and optgroup
Not free multi-line text (that was textarea)
Next: <datalist> for suggested values with typing still allowed

🧠 Test Your Knowledge

Ready to Start

Test Your Knowledge

Challenge yourself with this interactive quiz and see how well you understand the topic

❓

Questions

🎯

70%

To Pass

♾️

∞

Time

🔄

∞

Attempts

📝 Instructions

Read each question carefully
Select the best answer for each question
You can retake the quiz as many times as you want
Your progress will be shown at the top