In HTML, what does pairing an <input list> with a <datalist> actually give you, and when is it not enough — forcing you to build a custom combobox?
answer
- suggests, never constrains
- browser owns the popup entirely
- no filtering, styling, or grouping control
- closed value set means select instead
- rebuilding it means the full combobox pattern
basics
~20 sA datalist attaches browser-rendered suggestions to a text input while leaving it free-text: zero script, native mobile behaviour, no constraint. It falls short when you need control over filtering, styling, rich or multi-line options, multi-select, or dependable screen-reader behaviour.
solid answer
~50 s`<datalist>` holds `<option>` elements and an input references it by id through the `list` attribute; the browser then offers those values as suggestions. It costs no JavaScript, works with several input types, and on mobile you get the platform's own picker. Crucially it only *suggests* — the user can still type anything, so if the value must be one of the options you need real validation or a `<select>` instead. The limits are real: you cannot control the matching algorithm, style the popup, put rich or two-line content in an option, allow multiple selections, or rely on consistent screen-reader announcements across browsers. When any of those matter — an async remote search, token entry, result counts announced to assistive tech — you are building a real combobox, and that means the full ARIA pattern with keyboard handling, which is a component you should take from a tested library rather than hand-roll.
code
html · 7 lines<label for="city">City</label>
<input id="city" name="city" list="cities" autocomplete="off">
<datalist id="cities">
<option value="Berlin">
<option value="Bern">
<option value="Bergen">
</datalist>go deeper
Know that a datalist supplies suggestions to an input through the list and id attributes, that it needs no JavaScript, and that the user can still type a value that is not in the list.
Explain the suggest-versus-constrain distinction and derive the choice between datalist and select from whether the value set is closed. Be able to name concrete limits: no styling, no control of matching, no multi-select.
Demonstrate the build-or-use decision with reasons, including the inconsistent assistive-technology support that makes the popup unsuitable for announced result counts, and be honest about the full cost of the combobox you would otherwise own.
Own the policy: which of these patterns your design system supports, whether the combobox is a single audited component rather than per-team reinventions, and how you keep teams from styling their way out of a native control by accident.
## What the markup is A `<datalist>` is a container of `<option>` elements that is not itself rendered. An input points at it by id: ```html <label for="browser">Browser</label> <input id="browser" name="browser" list="browsers"> <datalist id="browsers"> <option value="Firefox"> <option value="Safari"> <option value="Chrome"> </datalist> ``` As the user types, the browser shows matching values in its own popup. An option may also carry a `label` attribute; browsers differ in whether they display it alongside the value, so never make meaning depend on it. ## The property that decides everything: it suggests, it does not constrain This is the single fact interviewers listen for. The list is a set of *hints*. The user may type a value that appears nowhere in the datalist and the form will happily submit it. That is a feature when free text is legitimate — a search box, a city field, a tag you may be inventing — and a bug when the value must come from a fixed set. So the choice is not "datalist versus select" on looks; it is a data question. If only the listed values are acceptable, use `<select>`, whose options are the only possible values. If free text is acceptable and the list merely accelerates typing, use a datalist — and if the free text must still match a shape, add real validation attributes on the input, because the datalist adds none. ## What it buys you - **No JavaScript, no component.** The popup, the matching, the keyboard interaction and the dismissal are the browser's problem. - **Native platform behaviour**, including on mobile, where the OS renders the suggestion UI in the way its users already know. - **It works with more than text.** `list` is honoured on several input types: with `type="range"` the options become tick marks, with `type="color"` a suggested swatch palette, and with the date and time types a set of suggested moments. The options must be valid values for that type or they are ignored. - **It degrades harmlessly.** Where the popup is unsupported, you are left with a plain text field that still works. ## Where it runs out - **You do not control matching.** Whether the browser matches on prefix or substring, case sensitivity, ordering and how many rows it shows are all decided for you and differ between browsers. Fuzzy matching or "best result first" is out of reach. - **You cannot style or measure the popup.** It is browser chrome. No highlighting of the matched substring, no icons, no two-line rows, no grouping headers, no footer with "see all results". - **You cannot open, close, or inspect it.** There is no markup or reliable way to force it open, so "show the top ten on focus" is not a thing you can promise. - **Announcement is inconsistent.** Screen-reader support for the datalist popup varies by browser and platform. If "12 results available" must be announced reliably, this is not the control. - **One value only.** No multi-select and no token/chip entry. - **Async is awkward.** You can replace the `<option>` elements as results arrive, but since you cannot control when the popup opens or how it filters, the experience is at the browser's discretion rather than yours. ## What a custom combobox actually costs Once you decide to build it, you own the whole widget. A text input marked `role="combobox"` with `aria-expanded` reflecting the popup state and `aria-controls` pointing at a `role="listbox"` whose children are `role="option"`; a highlighted option tracked with `aria-activedescendant` while DOM focus stays in the input; `aria-selected` on the chosen option; keyboard support for Down, Up, Home, End, Enter, Escape and Tab; click-outside dismissal; scrolling the highlighted option into view; a live region if the result count should be announced; touch and virtual-keyboard behaviour; and verification against actual screen readers, not just an accessibility linter. That is why the honest senior answer is a decision rule rather than a preference. Use the datalist when the list is short and static, free text is acceptable and the interaction is "help me type". Reach for `<select>` when the value set is closed. Build a combobox only when filtering control, rich rows, multi-select or async results are genuine requirements — and then take a tested implementation of the established pattern instead of writing one from scratch, because the failure mode of a hand-rolled one is a control that keyboard and screen-reader users cannot operate at all.
- A field must accept only one of twenty known values. Would a datalist be a correct choice?No. A datalist only suggests — the user can type anything and the form still submits it, so a closed value set is not enforced. Use `<select>`, where the options are the only possible values and the browser guarantees it. If the interaction genuinely needs typing to filter twenty items, that is a combobox with a selection requirement, and you enforce the requirement yourself rather than trusting the suggestion list.
- Can you use a datalist for a remote, as-you-type search?Only loosely. You can swap the `<option>` elements as results arrive, but you cannot control when the popup opens, how it filters what you supplied, its ordering, or how many rows it shows, and you cannot announce result counts reliably. For a genuine search-as-you-type experience with loading and empty states you need a real combobox, where you own the popup.
- Which input types honour the list attribute, and what does the suggestion UI look like for them?Beyond plain text and search it works with url, tel, email, number, the date and time types, `range` and `color`. The rendering follows the type: a range shows the option values as tick marks on the track, a colour input offers the listed values as a suggested swatch palette, and date types offer suggested moments. Options that are not valid values for the type are ignored.
saying these in an interview costs you the question
- Believing a datalist restricts input to its options
- Expecting to style the suggestion popup
- Assuming filtering behaves identically across browsers
- Reaching for a div-based dropdown for styling reasons alone
- Calling a custom combobox accessible without screen-reader testing