The current autocomplete supports multiple complete (ala GMail "send to" field), but it really is rather broken: You can add values, and some callback is triggered for each value. But you're really lost once the user starts removing values. This is a problem when the display value maps to some id or index.

I think what the autcomplete needs for that to work properly is some more internal state: A stack with selected rows that is always in sync with the input field. When the user removes something from the field, the actual data row is removed from the stack as well. When values must match, which is usually the case when this behaviour is required, editing a value removes it from the stack as well, and therefore from the input on the next update.

That way it would be trivial to remove values from the input: Just delete one character, and the rest of the term is removed as well.

@Andrew Powell - great news. A great place to start would be Section 3. Functional Specifications/Requirements. In other words: we need to design it before we build it. For some examples of plugin pages with some specs already filled out, see:

http://wiki.jqueryui.com/Accordion
http://wiki.jqueryui.com/DatePickerCalendar
http://wiki.jqueryui.com/Dialog
http://wiki.jqueryui.com/Draggable
http://wiki.jqueryui.com/Droppable
http://wiki.jqueryui.com/Slider
http://wiki.jqueryui.com/Sortable
http://wiki.jqueryui.com/Tab

Food for thought:

In Windows development, when you choose to use a ComboBox, you can set the behavior of the control to act as a 'DropDownList'. See http://msdn.microsoft.com/en-us/library/system.windows.forms.combobox_properties.aspx

The properties which are of interest to me are; AutoCompleteMode, AutoCompleteSource, and DropDownStyle (http://msdn.microsoft.com/en-us/library/system.windows.forms.combobox.dropdownstyle.aspx)

Perhaps it would be appropriate to rename this plugin 'ComboBox' and implement the autocomplete portion as a separate plugin/utility on which the ComboBox could then depend? Please share your thoughts.

Looking at the visual designs, I agree with seperating ComboBox and autocomplete. A ComboBox would be a specialized Autocomplete that doesn't allow any new entries.

I disagree calling the Autocomplete a utility. Its just as important on its own. Considering the similarity between ComboBox and a html select, I'd even argue that the Autocomplete should have a higher priority.

It should be easy enough to split my old demo into individual demos based on the current demo format. To assert that this functionality keeps working, tests based on that would be the next step. Only then is refactoring and extending safe.

About the URL exception: The plugin should be helpful in exposing common problems to the developer. It shouldn't make any descision on how to handle regular errors like connection errors. Usually those are handled by binding $().ajaxError. The plugin shouldn't swallow network problems.

@ Jörn

Please excuse the utility bit there. I'm still new the to project and didnt know what verbiage I should use there, so I included it to be safe.

I also have two instances of exceptions which were thrown, and your input on them would be much appreciated. Would you consider the following to be connection errors that we should let pass-through? (I'll post the actual Firefox exception message tomorrow if that's helpful)

- Cross Domain request exception
- Permission Denied exception (occurs in a very specific situation where credentials are required to access the url specified)

I don't agree that a combobox never allows people to enter a new value, although sometimes it is (mis)used that way in some cases. In fact, that seems like the wrong UI widget for the job. If you cannot enter a new value and must choose from a list of values, a select (dropdown) is the better element to use because it provides a clearer affordance of this constraint. Selects do not look editable like an input to cue the user into the fact that they are choosing from a set list, not typing something new in.

A combobox should be used for cases where users can enter a new value (that's why it looks like an input) or pick from a preset list (button with down arrow to the right of the input). The URL bar in a browser is a classic example of a combobox: http://en.wikipedia.org/wiki/Combo_box -- you can type something new or pick from values.

Some comboboxes will pre-fill with the best match value as the user types, but I think it's used in many cases to force a user to only choose from a preset value which is sort of odd (see argument above). This is the MSFT 'DropDownList' option Andy mentioned and Apple does it too (See pref panel for timezone) but it is an exception, not the rule. I think they do this because selects only allow for searching on the first character (dunno why - no feedback on search characters?) but sometimes you need to let people enter multiple characters to winnow down to the right value and a select doesn't offer this capability.

If we created a custom select built on top of autocomplete, it could bold the matching letters for a visual affordance and allow for multi-letter searches - as you type letters, it selects the best match. That would be a better solution than this hacky combobox with select behavior thing.

We've done some work on a PE based list builder which is basically the multiple recipient GMail example you mention. The best solution would start with either an input of textarea that can be populated with a set of comma/space/semi-colon (or whatever) delimited list of items that is enhanced into the whizzy auto-complete UI like Facebook or GMail. As a user adds or removes items, we update the original input/textarea and that serves as the "stack" to keep track of the items while also being a simple html element. Scott J. can post an example later this week if that would help.

>> The best solution would start with either an input of textarea that can be populated with a set of comma/space/semi-colon (or whatever) delimited list of items

That demo is in the dev branch too :)

branches/dev/autocomplete/demos/autocomplete/bassistance.de.html - 'Multiple Cities'

@Todd: Dylan, who built the original autocomplete plugin, created it for an application where the user could choose a value from a list of birds. The list is way too big to fit into a regular select, while new values weren't allowed. And there are a lot of scenarios like that, eg. City or Street names. Whatever our solution, it must supports this usecase.

@Andy - Thanks for the tip, I never would have found that demo (I get lost in all the branches). Here the link:
http://jquery-ui.googlecode.com/svn/branches/dev/autocomplete/demos/autocomplete/bassistance.de.html

...The multiple city with 'must match' is tricky from an interaction perspective. In this demo, if you start typing a city name (Boston) that isn't in the list when you get to "Bos", the script *deletes* the word when the "s" is Bos is typed because it doesn't match which feels really odd.

@Jorn From the demo, this is shaping up very nicely Jorn! Do you have an example of the autocomplete suggestion displaying inside the text input instead of a menu (see Apple screenshot at top). I agree that these 3 items should be separated out with autocomplete being finalized first because it's a dependency for select and combobox.

I didn't mean to suggest that the combobox shouldn't offer the 'dropdownlist' type option which would prevent new values from being entered, it should. I was just explaining that behavior should not be the *default* for the combobox since it's a bit of a misuse of the element and can be confusing to users that they are allowed to type but the system deletes their input like in the city example. Making the custom select allow for multiple letter searches would be a nice alternate that would accomplish the same thing but with a clearer affordance that new values aren't allowed.

I may have misunderstood you when you said above "A ComboBox would be a specialized Autocomplete that doesn't allow any new entries." -- I thought you were saying this is the default (or only behavior), but I think you meant that should be an option.

Yeah, thats more like it. I meant to describe the ComboBox as its own widget, where the implementation builds upon the autocomplete widget. With the ComboBox being more similar to a native select, but the ability to handle much larger datasets.

Displaying the dropdown-icon in the text input field should probably be an option of the autocomplete widget in any case - the ComboBox widget would then always enable it.

Multiple must-match autocomplete is indeed tricky. Just removing the user input is not a good interaction. Ideas for alternatives?

The Apple-style autocomplete isn't yet covered in the existing demos, and probably needs some modifications. Enable autoFill and make the autocomplete work without display the select box.

@ Jorn

>> Displaying the dropdown-icon in the text input field should probably be an option of the autocomplete widget in any case - the ComboBox widget would then always enable it.

In what other situation would the autocomplete plugin add a similar button? Just playing devil's advocate here, but wouldnt adding the button to the autocomplete plugin be out of scope? It seems much more logical, and flexible, for a plugin like the comobox to implement the button, which triggers the autocomplete plugin/menu.

The button is a easy-to-find control to open the autocomplete list any time, producing the same result as a key input would otherwise. The currently plugin enables similar behaviour with a double click (focus field first, then click), but this behaviour is very hard to find, and I've seen a lot of requests for a button or some other way to open the select.
If something is actually displayed still depends on the content, eg. an empty input with minChars: 2 wouldn't display anything.

Ah, that's a cool feature!

In that case, if we had a combobox plugin and it rendered a button, couldn't the combobox instruct the autocomplete to do it's thing when the button was clicked? I'm still in favor of plugins using the autocomplete plugin, rendering their own UI elements and instructing autocomplete on what to do when.

I would like to see a tree select for one or many.

It would be a good replace for select with options like:
Option1
Option1 > Option11
Option2
Option3
Option3 > Option31
Option3 > Option32
Option3 > Option32 > Option 321

Or something like this:
Option1
--Option11
Option2
Option3
-- Option31
-- Option32
---- Option 321

<img src="/f/treeselect.png"/>

Ups, the wiki does not support img. You can see a mockup here: https://jqueryui.pbwiki.com/f/treeselect.png