A way to make <datalist> contain exhaustive options

[WebWeWantBot]

---

title: A way to make

• 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

The use case for this is pretty much the same as or a radio button group. The difference is that, combining an and a

The alternative could be, improving the element, to make it searchable. But I do feel limiting = radio button group; = checkbox group.

---

If posted, this will appear at https://webwewant.fyi/wants/63859591efcacd02a297cd3d/

aarongustafson commented 1 year ago

@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 commented 1 year ago

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.

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[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.