[whatwg] input element list attribute and filtering suggestions

[Ian Hickson]

On Mon, 2 May 2011, Jonas Sicking wrote:
> On Mon, May 2, 2011 at 3:32 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 31 Dec 2010, Jonas Sicking wrote:
> >> >
> >> > The thing that makes this different than "Google suggest"-style UI 
> >> > is that in the latter case you need a script that continually polls 
> >> > for more appropriate suggestions and updates the list -- for this 
> >> > kind of thing we'd probably want to use a direct API, we wouldn't 
> >> > want to have scripts have to poke at the <datalist> DOM in real 
> >> > time.
> >>
> >> Why not?
> >>
> >> The firefox implementation should allow this (though I haven't tried 
> >> this myself). Feel free to try it out and let us know how well/poorly 
> >> it works.
> >
> > I just meant that it would be a poor authoring experience. I agree 
> > that it should in theory be possible with the current API; it just 
> > seems that if that's the use case we want to address, we should 
> > instead just have people point to a URL and be done with it:
> >
> >   <input type=text autosuggest="/cgi-bin/autocomplete.pl">
> >
> > ...or some such.
> 
> Sure, but that seems like a significantly more complex solution to 
> design. We'd likely have to add features like deciding how many 
> milliseconds to wait for another keystroke before sending the request. 
> We'd also have to come up with a file-format for the response, and a 
> definition of how the typed value is supposed to be sent with the 
> request.

Yes. Doing the hard work to make it easier for authors is our job. :-)


> I'd also be worried about making it possible to write keyloggers on 
> sites that filter out scripts, but do allow form controls to be 
> inserted.

These would presumably be forms that cannot be submitted? I'm not sure I 
understand how this attack scenario would work in practice.


On Tue, 3 May 2011, Aryeh Gregor wrote:
> On Mon, May 2, 2011 at 6:32 PM, Ian Hickson <ian at hixie.ch> wrote:
> > I just meant that it would be a poor authoring experience. I agree 
> > that it should in theory be possible with the current API; it just 
> > seems that if that's the use case we want to address, we should 
> > instead just have people point to a URL and be done with it:
> >
> >   <input type=text autosuggest="/cgi-bin/autocomplete.pl">
> >
> > ...or some such.
> 
> This is too inflexible.  It splits the logic between the browser and 
> server in a rigid way, and doesn't allow client-side script to have any 
> say.  It would be much more useful to have a script API that lets you 
> assign a list of suggestions to an input.  Basically the same 
> functionality as datalist, just easier to script.  This way, the author 
> has control over when and how the results are fetched and displayed, can 
> use any format on the server side, can retrieve results from the client 
> side if they like, etc.
> 
> There's no need to use the subjunctive here, by the way.  As I said, I 
> did actually write such a search-suggestion thing for MediaWiki using 
> the datalist API, and it works great in Firefox 4 as far as I can tell.  
> It was just complicated unnecessarily by the need to add datalist 
> elements to the DOM instead of plugging a list directly into the input.

We could certainly also support scripted delivery of the suggestions.


On Tue, 3 May 2011, Jonas Sicking wrote:
> >>
> >> It seems to me that a simple boolean attribute and a few lines of 
> >> script solves 80% of the use cases.
> >
> > What boolean attribute would that be?
> 
> The mozNoFilter attribute we added in Firefox 4.

On Wed, 4 May 2011, Aryeh Gregor wrote:
>
> I don't see any use-case where you wouldn't want to use mozNoFilter. Why 
> doesn't it just work that way always?

On Mon, 9 May 2011, Mounir Lamouri wrote:
> 
> Basically, when you want to use the datalist to suggest a few things you 
> might not want to filter and when the list is long, you very likely want 
> to filter.
> 
> You might not want to filter when the list is a real set of suggestions 
> and you can type anything else. For example, a field in a support form 
> can ask you "What is your problem?" and you could type a brief summary 
> but some pre-written issues will be available. It's equivalent to a 
> select element followed by an input field that you can use if you select 
> "other" in the list. As I see it, when you filter, you have a very long 
> list and you very likely want the user to select something in the list 
> like a list of bugzilla emails, a list o metro stations, etc. Writing 
> anything not in the list might not work.

So why don't you just automatically filter if the list is long, and not 
filter if the list is short?

I don't really understand the reason for this attribute.



I haven't added anything to the spec yet.

I think mozNoFilter is unnecessary; UAs should be clever enough to 
determine when the UI would be better with filtering and when it would be 
better without. This seems rather trivial as it is (just filter when the 
list is greater than seven, and don't filter the list to zero unless 
you're confident that none of the suggestions apply at all).

I think there is a use case for script- or server-driven suggestions for 
which we could do a more targetted feature, distinct from the current 
feature which is optimised for the static autocomplete combo box case. 
However, I think we should wait a while to get the implementations 
solidified and to see how people use the current feature before adding 
more stuff here.

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