Align implementation "search" behavior for <input> with <datalist>

[travisleithead]

Moved from Bugzilla bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20400 (also cloned in w3c/html#236)

@nicksloan (I think this is the same you)

Back in September, I identified some issues with the datalist element and related portions of the spec that led to questionably usefulness. Here is the post to the mailing list: http://lists.w3.org/Archives/Public/public-html-comments/2012Sep/0006.html

The biggest barrier to usefulness of this feature is that it doesn't define a way to show a label to the user, rather than the value. Consider the following:

<datalist id="users">
<option value="1" label="Nick">
<option value="2" label="Hank">
<option value="3" label="Frank">
<option value="4" label="Nick">
</datalist>

<input type="text" list="users">

I can't guarantee that the names of my users will be unique, making name an unsuitable field for the value of these options. So instead I choose to use an id integer from the database row... a very common practice on the web. The problem is the user experience: the id isn't something that users know or care about, so making it the criteria that users search on, and the label displayed to them upon selection is not effective.

To solve the searching aspect of this issue, user-agents should be instructed to also search on the label field at minimum. Additionally, user-agents should give expose an attribute or API that allows developers to tell the input whether to search based on label or value. It may also be helpful to include APIs for letting the developer define how searching works.

To solve the presentation issue in search results, only the label should be shown if it is present. Otherwise, the value should be shown.

There may be a simple solution to the presentation of the input element's value. Displaying a select element as a search box when a list attribute is present might make a lot of sense. This already shows a label rather than a value, and can scale up to support multiple selected items pretty naturally. Think along the lines of how Chosen.js works (http://harvesthq.github.com/chosen/). The datalist feature is clearly meant to enable the same sort of interactions that Chosen.js does, so using Chosen as a model for the feature seems reasonable.

There may be another option if you let developers display one value in an text input element and submit another, but that seems potentially very messy.

I created https://jsfiddle.net/ze6ex44b/ to see what's happening in this space today. Results are varied among the browsers I tested:

Search type	Edge	Chrome	Firefox
Search by option value	X	X
Search by option label			X
Display option value		X
Display option label	X	X	X

Seems like an area to resolve some interop differences :)

[domenic]

Thanks for filing. It seems like there's two important things to do here:

• A compat clarification: specify whether browsers should search by value, label, or both. We could probably specify by value for now and see if we can get implementer interest for both.
• A feature request: add an attribute to control how the search works

As for rendering, it's not the HTML spec's responsibility to say how things are rendered---it's agnostic to presentation, whether it be visual, aural, terminal, or braile. That said, there's already an example that displays both: https://html.spec.whatwg.org/#url-state-(type=url) in the visual presentation.

[nicksloan]

Thanks @travisleithead and @domenic for following up on this! It's been a while, but I'm thrilled to see that there is still interest in getting this right. I don't know how much I am able to do, but if there is something I can do I would be glad to help.