Bug 20400 - datalist Spec Oversight Limits Usefulness
Summary: datalist Spec Oversight Limits Usefulness
Status: NEW
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
Depends on:
Reported: 2012-12-15 01:16 UTC by Nick Sloan
Modified: 2013-01-07 12:17 UTC (History)
5 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Nick Sloan 2012-12-15 01:16:14 UTC
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">

<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.
Comment 1 Tab Atkins Jr. 2012-12-15 02:10:36 UTC
If you display the label, but the label is non-unique, how do you expect the *user* to be able to pick the correct choice?  This lack of uniqueness makes the entire feature useless to you, whether or not there's a hidden unique value associated with each option.
Comment 2 Nick Sloan 2012-12-15 03:08:01 UTC
Very good comment. One possible way of addressing that would be adding additional information to the item to make it unique. Maybe I display the user's email address after the name, or a unique username. An even better solution would be to display a profile image for the user, if the user-agent supported styling options (tangentially, allowing images in the option element's content would be nice). Perhaps I display information that (like Facebook) gets close enough to unique that most users can tell who is who.

If I do create a unique display string, you might argue that I can just parse it out on the server. That would be an acceptable solution if the label/value paradigm didn't already exist on option elements to solve this exact problem in other use-cases.

The most important thing is giving developers the flexibility that they need to create great experiences for their users.