HTML5 Datalist Element and Input Element's List Attribute Dead on Arrival

The UX for the HTML5 datalist element/list attribute feature is
unusably bad in every browser. To the extent that users will continue
to favor a javascript solution over the HTML implementation rather
than subject their users to an experience that is often broken,
confusing and ugly.

When browser vendors implement a feature like this so poorly, the spec
must be looked at as a source of blame. After reading the spec, I
believe that to be the case here. It is ambiguous and leaves critical
decisions up to the user agent. Without consistency on a fundamental
level among user agents, the web as a platform cannot succeed. That is
the whole reason for this spec.

If one were reading the spec, the issues in it may not be apparent
because of the simple examples used. Let's consider a more realistic
example. I have an input that will submit a user id. To make this easy
for users, I supply a datalist element to suggest user ids to the
user. My user ids are UUIDs, so instead of displaying those, which
likely mean nothing to my user, I want to use a label to display the
names of the user. I have something like this:

<input type="text" list="users">
<datalist id="users">
<option value="1ffb3722-314e-42c0-b8c5-288aaf0b37b8">Nick</option>
<option value="9f3798b3-de1e-4adf-b71c-a4a4e01dde3b">Mike</option>
<option value="7a1b0a0a-06d0-4398-a610-9b3db4635944">Rachel</option>
</datalist>

This is a more realistic example than the ones presented in the spec
of treating a properly cased name as the label and value.

The first issue is that the spec does not specify how the datalist is
to be searched when filtering based on user input. Presently, Chrome
matches from the beginning of the value string only. Firefox matches
from anywhere inside of the label string, and ignores the value
string. I haven't tested Opera and Internet Explorer. I'm afraid to.

The second issue is that the spec is ambiguous on what the user agent
should display when presenting suggestions: Chrome shows the value and
label, side by side. Firefox shows only the label. Neither of these
implementations would be considered incorrect by the spec as I read
it, nor would be ignoring the label and showing only the value. Once
again, the spec is open-ended on this subject.

The third issue is that the spec is silent on how the suggestion
should be inserted into the input. The browsers are at least
consistent on this point, and in all fairness, I don't know that HTML
allows for a better solution. That doesn't mean that the implemented
solution is correct though. When selecting an option, the value is
inserted into the input. In Firefox, this means that the name that the
user selected is replaced with a long string of numbers and letters
that the user has never seen before, in the case of my example. In
Chrome the experience is slightly better, since I am at least shown
the values before selecting the option, which may make the appearance
of the value less surprising. But imagine I have 20 people to add to a
list of input elements that rely on the users datalist. I can't look
back at previous input elements to see who I have added in a practical
way. This is simply broken, and makes the list attribute/datalist
feature unusable.

I propose that the spec should take a stance on how options are
filtered. Matching at any position, case insensitively, in the label
seems to be the most useful experience, however, matching against both
the label and value wouldn't be awful either.

I further propose that the spec should express the proper
implementation for the second issue raised above. If the value must be
inserted into the input element, it should also be displayed as a
suggestion.

Finally, I propose that some consideration be given to a means by
which the input element can submit the value while displaying the
label of the chosen option. This is supported in the case of many
other input types, but I can understand why this makes less sense for
an input type of text. Surely there must be some sane way of doing
this though.

Received on Sunday, 30 September 2012 16:58:50 UTC