[whatwg] input element list attribute and filtering suggestions

[Jonas Sicking]

On Fri, Jul 29, 2011 at 4:24 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> On Fri, Jul 29, 2011 at 3:42 PM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> >> On Fri, Jul 29, 2011 at 3:22 PM, Ian Hickson <ian at hixie.ch> wrote:
>> >> > On Fri, 29 Jul 2011, Jonas Sicking wrote:
>> >> >>
>> >> >> The problem is the other way around. When wanting to show a short
>> >> >> list that should be filtered based on user input.
>> >> >
>> >> > Why would it matter if the list is filtered or not when it's short?
>> >>
>> >> Choosing something at the bottom of a 10 item list is likely about as
>> >> annoying as simply writing the whole email address manually and ignoring
>> >> the <datalist> feature completely.
>> >
>> > If 10 items is annoying, then it's not short.
>>
>> You mean "long", right?
>
> No, I mean "short". I said that it shouldn't matter if you filter or not
> when the list is short. You said that a list with ten items was annoying.
> I'm arguing that that means the list is long, and thus not short, and
> thus should be filtered.
>
> My overarching point, however, is that this is a UI issue, and not an
> authoring issue. Authors should be able to provide either a complete
> static list of autocomplete suggestions, or a shorter list of relevant
> suggestions based on the current user input. In both cases, the user agent
> should be able to prioritise and/or filter the given suggestions in
> whatever manner makes the lists most helpful to the user. Giving the
> author the ability to prevent the filtering altogether makes sense if the
> UA's filtering is not ideal, but it doesn't make sense to put in the
> standard, since it's not yet at all clear that an ideal filtering is
> simply impossible.
>
> If, in the future, we find that it is in fact impossible for a UA to be
> clever enough to have good UI whether the list is static or dynamic, short
> or long, prefiltered or not, then it would make sense to study what
> further controls we can give authors. It would make a lot of sense to look
> at this at the same time as we look at other suggested augmentations here,
> such as the ability for script to provide prefiltered suggestions directly
> rather than having to manipulate DOM nodes to do so.

I have no idea how the UA would be smart enough to figure out if
filtering makes sense or not based on the set of suggestions. As far
as I can see this requires very complex AI which is able to analyze
the set of suggestions and see if they are contextual to the entered
value or not. Granted, the recent IBM computer Watson did a pretty
good job at this on Jeopardy a few months ago, but I think that we're
decades from having that amount of computational complexity at our
disposal when filtering autocomplete suggestions. I'd be nice if
<datalist> was a viable solution before then.

>> >> Has any browsers implemented the UI you are suggesting? Is any
>> >> planning to?
>> >
>> > I've no idea. It's incredibly early days in terms of implementations
>> > of these features. We are still looking for better ways of
>> > implementing maxlength="", which is something like 15 years old now.
>> > It'd be a little premature to dismiss something so early on.
>>
>> The ability to configure UI has been one of the big problems with the
>> existing set of forms, and is one of the biggest concerns with the new
>> set of forms (in particular the complex widgets like date/time pickers),
>> so your argument that this particular aspect does not need to be
>> configurable from the page seems like something that needs some backing
>> up with more than opinions.
>
> I do not think the premise of this argument is correct.
>
> Styling form controls has certainly been something we have failed to
> provide hooks for, but that's an orthogonal issue, IMHO, and should be
> resolved using some sort of widget binding solution, not more attributes
> in the language itself.
>
> If we had a widget binding solution then authors with especially
> complicated needs could just override <input> and provide an
> implementation of the widget that did exactly what they wanted.

Are you suggesting that filter/no-filter should be selected using CSS?
That seems outside of what CSS currently does anywhere.

/ Jonas