A way to make <datalist> contain exhaustive options

[WebWeWantBot]

---

title: A way to make contain exhaustive options
date: 2022-11-29T05:16:01.978Z
submitter: Zacky Ma
number: 63859591efcacd02a297cd3d
tags: [ ]
discussion: https://github.com/WebWeWant/webwewant.fyi/discussions/
status: [ discussing || in-progress || complete ]
related:

• title:
  url:
  type: [ article || explainer || draft || spec || note || discussion ]

---

(Sorry for submitting a duplicated entry, but I put the wrong email, zacky@marchbbox.com. This entry has the correct email, zacky@marchbox.com)

Current contains options that are permissible or recommended. But often we want it to contain the exhaustive options, meaning a user has to choose one of the options in the given , if the related receives a value that is not on this list, the should be considered invalid.

The use case for this is pretty much the same as or a radio button group. The difference is that, combining an and a makes it easier to find a value. This is particularly useful for form fields like "Country", "State", etc.

The alternative could be, improving the element, to make it searchable. But I do feel limiting to recommended options only is a missed opportunity. We could have multiple ways of achieving the same goal, e.g. = radio button group; = checkbox group. If posted, this will appear at https://webwewant.fyi/wants/63859591efcacd02a297cd3d/

[aarongustafson]

@marchbox If you want to be restrictive in the choices, you should use a select. The datalist approach is intended to allow free-response in addition to suggestions. Incidentally, I just wrote a piece about "choose one" type fields for HTMHell that will come out in a few weeks as part of their advent calendar.

Also: Both select and datalist are searchable based on the visible text of their option elements. Searches are not fuzzy though, and are based on the start of the text. I haven’t followed it too closely yet, but there is work in OpenUI to build a new form of select called selectmenu. It is fully styleable and may be customizable enough to support fuzzy searching.

[marchbox]

Thank you! I'm looking forward to the article. I do want to understand the decision behind this. As of right now, from HTML author and end-user perspectives, I can't think of any downside of giving this option. And given how complex to implement an autocomplete UI component especially when we take accessibility into consideration, I think it'd be great for end-users if we have the behavior built-in in browsers. And following that direction, I think a restrictive <datalist> is a good way to start since it's half way there already.

Searching with <select> is pretty hard to discover and use for regular users, a user usually has to type really fast to get multiple characters registered, and it doesn't usually work for languages like Chinese. In the "Country" field case, I often typed too slow and the auto selected option jumped from a "U" option to an "N" one.

I'm loosely following <selectmenu> updates, but I think it's solving a different issue (customization of <select> elements), but hopefully its flexibility could allow more complex listboxes, like one with a search box.