[whatwg] input element list attribute and filtering suggestions

[Ian Hickson]

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.


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

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'