Inspect the working example
The text input points to a datalist containing two synthetic editor names. The exercise asks you to type Other editor, which is absent from the suggestions. No business-record match or permission follows from that entered text.
| Case | Input or inspection | Result and meaning |
|---|---|---|
| List reference | Resolve input.list | datalist id=editors, with two options |
| Suggested text | Enter Text editor A | Input retains the text; validity.valid=true |
| Unlisted text | Enter Other editor | Input retains it; validity.valid=true |
Follow the browser mechanism
list associates the text input with a datalist of suggestions. It does not restrict the text value to those options. If a task requires a known identifier or an allowed choice, define a separate validation rule or choose an appropriate restricted control. Suggestion popup behavior and presentation depend on the browser and platform.
A suggestion list does not prove a known value
This counterexample starts with an unlisted value while still supplying the same list. It exposes the mistake of using list presence as evidence that the input is a recognized record.
<label for="editor">Preferred editor</label><input id="editor" type="text" list="editors" value="Other editor"><datalist id="editors"><option value="Text editor A"></option><option value="Text editor B"></option></datalist>The unlisted value is retained and native validity is true. Neither that flag nor the datalist proves a matching option exists.
Try the repair
The field contains Other editor and validity.valid is true. Can you infer that it matches either supplied suggestion?
Show the worked answer
No. The value is a valid text-input value under these native constraints, but it matches neither suggested value. Validate membership separately if the task requires it.
- Assert the actual list association and two option values.
- Test unlisted input; do not claim identical native suggestion menus across systems.