Summary

  • datalist supplies suggested values to an editable input through the list attribute; the user can still type a value of their own.
  • The browser chooses how to present and filter suggestions, while the author chooses the list and ordinary input validation still applies.

Imagine a clerk who slides a card across the counter with seven likely answers and then waits quietly while you write an eighth. Web forms have often preferred the other kind of clerk: a menu that insists your life fits one of its boxes. datalist gave HTML a gentler middle ground. The author offers examples, the browser presents them near an editable field, and the visitor can keep typing. The form has opinions. It has learned to stop treating those opinions as a border checkpoint.

The W3C’s first public HTML markup draft in March 2010 marked datalist as new and described it as a source of predefined options for other controls. Its contents could include option elements along with fallback material for older user agents. That detail catches the era: new browser behavior had to coexist with pages visited by older browsers. A suggestion box was being written into the language while the document still left a way for the older reader to see useful material.

The 2011 W3C markup reference kept the core definition: a set of options for other controls. The phrase “other controls” is doing important work. A datalist is a source of suggestions; it is not the field where the answer finally lives. The form author can maintain one list, and an input can point to it. This division separates the curator from the typist. One side proposes familiar entries. The other side records what the person actually chose or wrote.

The maintained HTML Standard’s form section gives the mechanics a precise shape. A datalist contains option elements; a non-disabled option with a non-empty value represents a suggestion. Each suggestion may have a value and a label. An input connects to the list through an ID named by its list attribute. The label can help identify an option; the value is what selection puts into the field. The same visual suggestion can therefore carry a human-friendly description and a machine-friendly value.

The input rules make the browser an active participant. It should offer suggestions while the user edits the field and may filter a long set. The standard recommends matching both labels and values, accounting for Unicode normalization and case. That matters when two keystrokes look identical to a person but use different code-point sequences under the hood. A good suggestion system meets the reader where they type, rather than demanding that the reader guess the list’s exact spelling.

When someone selects a suggestion, the browser sets the input value as if that person had typed it. The phrase matters because the suggestion joins the normal input flow. A user who types a different valid value remains in the same field; the author’s list has not become a fence. An input type and its ordinary constraints still govern what counts as acceptable. The list can help with a common airport name, for example, while a less common destination can still be entered if the field permits it.

That is the quiet bargain behind datalist. The author gets to make good guesses; the browser decides how best to surface them; the reader keeps the final pen. A menu can be efficient when the answer space is truly closed. This device serves the much messier world where useful defaults coexist with legitimate surprises. The most humane form may be the one that says, “Here are a few ideas,” then leaves enough room on the line for yours.