> 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 <[email protected]> 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. > >
