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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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

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


Reply | Threaded
Open this post in threaded view
|

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

Arthur Clifford
> 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.
>
If filtration is an option there should be a filterAttribute attribute, possible a filterCase, and generally a filterFunction.  Though I imagine folks here would make filterAttribute and filterCase css styles. The filterFunction could be passed the values of filterAttribute and filterCase along with the current value. filterFunction would return 0 or 1 for disinclude or include respectively. Presumably there would also be filter criteria that would likely take a regex pattern to find matches on, if that were true then /apattern/i would give you case insensitivity. However, if user agent's aren't told what to filter on that is sort of silly. Of course, in a custom filter function you should get the whole option not just the value or the label so that a developer can choose any aspect of the option (including id,class, or other attributes) to use.

> 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.
The value should not be inserted into the input field; user agent developers who do that and promote it as good should be publicly flogged. The whole point of lists is to provide a human friendly label to obscure the human unfriendly value. For forms, it was a way of presenting something digestible to the user and having something gnarly if need be to send to a server to handle. UIDs are indeed un-pretty, but aesthetically gorgeous compared to a long url encoded parameter list.

> 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.
Consideration? that should be etched in stone and announced through a burning bush from a a mountain-top. Label=display, value=submission content. So it SHALL BE written, so it SHALL BE done.

Nicholas is being polite, allow me to translate: fix the spec so it is actually specific and states the obvious so user-agent developers who hire developers too young to understand the history of html and its purposes don't do stupid things like display values in lists and submit labels.

If the label should be in a label attribute rather than the content of the input element that apparently is not clear to Nicholas. I realize there is a probability Nicholas missed something, but apparently it is easy to do so. Either way his points I think warrant a review and update of the relevant part of the spec.

Art C

suggestion.On Sep 30, 2012, at 9:29 AM, Nicholas Sloan <[hidden email]> wrote:

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


Reply | Threaded
Open this post in threaded view
|

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

Mounir Lamouri-3
In reply to this post by slango
On 09/30/2012 05:29 PM, Nicholas Sloan wrote:

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

Actually, I think Firefox would have a decent behaviour if it was not
showing the value when selecting an item in the list. Ideally, it should
show the label of the item and insert the value in the input's value.
Unfortunately, we do not support showing a different string than the
input's value for the moment.

> 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 agree that we could improve filtering. For example, Firefox has a
mozNoFilter to disable filtering. We could have better control no how
the list is filtered too.

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

I doubt all of that needs to be spec'd. What is exactly shown in the
list is part of browser's implementation details. For web pages, it
doesn't change anything. For example, if Firefox was showing the label
and inserting the value in the input field, it wouldn't change anything
for web pages with regard to how they interact with the feature.
However, it changes UX and if UX is bad in a browser, users can just
change browsers.

This said, the specs can always give some hints or recommendation or
even describe a probable UI.

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

That's indeed what I think we should do.

Cheers,
--
Mounir