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

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

Received on Monday, 1 October 2012 10:39:32 UTC