This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
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.
HTML5.1 Bugzilla Bug Triage: Moved to https://github.com/w3c/html/issues/236 If this resolution is not satisfactory, please copy the relevant bug details/proposal into a new issue at the W3C HTML5 Issue tracker: https://github.com/w3c/html/issues/new where it will be re-triaged. Thanks!