At first it may look like the new plugin supports barely any of the old options. We'll see how all the old options can be implemented using the three new options and the six events.

The old plugin had two arguments: data or url, and options. Lets start with that data-or-url argument. With the new autocomplete plugin, you'll just pass the data or url to the source option.

So, with the old plugin you'd have this code:

And that becomes, easy enough:

The same applies if you provided a URL as the first argument, although there is a difference between the two plugins for remote data. The old plugin expected a special format with pipes to separate values and newlines to separate rows. That is gone for good, the Autocomplete widget now works with JSON by default. The simplest form is the same as in the example above, an array of string values.

Instead of an array of strings, the widget also accepts an array of objects, with at least a label or value property, or both, in addition to whatever else you need. More on that can be found in the documentation and various demos, eg. the Custom Data demo shows how to use custom properties and even display them.

Lets look through the rest of the options for the old plugin, and what to do with them for the new plugin:

• autoFill: Gone with no immediate replacement available, for good reasons: The default behaviour when selecting items via keyboard now puts the focussed value into the input, like the Firefox Awesomebar does it. It's not the same as what the autoFill option did, but there should be no need to recreate that effect.
• cacheLength: There is no built-in caching support anymore, but it's really easy to implement your own, as shown by the Remote with caching demo.
• delay: Still exists with the same behaviour, but the default is always 300 milliseconds.
• extraParams: Extra params and all other Ajax related options can be customized by using a callback for the source option. Use $.ajax to send the actual request, with the response callback argument passed to source as the success callback for the $.ajax call. The Remote JSONP datasource demo has an example for that.
• formatItem, formatMatch, formatResult, highlight: All gone, instead use the source option to either provide the formatted data from your serverside, or implement a custom source to do special formatting. The combobox demo shows how to do that, with a more extensive explanation of that demo right on this site.
• matchCase, matchContains, matchSubset: All gone, too. The builtin matcher for local data will do a case-insensitive match-contains, everything else has to be implemented on the serverside or using the source option. The combobox linked just above also has an example for that.
• max: Gone; if your server sends too many items, pass a function for the source option that calls $.ajax and truncates or filters the resulting list.
• minChars: Still present, but was renamed to minLength. Behaves just the same, even the default is still the same, with minLength: 1.
• multiple, multipleSeperator: Not built-in anymore, but easy to recreate. There are two demos for this, once with local data, once with remote data.
• mustMatch: Gone, but easy to implement with the select event. Once more, the combobox provides an example for that.
• scroll, scrollHeight: These option are gone, but the underlying Menu widget actually has support for scrolling. If you have enough items and specify a height via CSS, the menu will scroll.
• selectFirst: Similar to autoFill (at the top of this list), this option is gone and has now immediate replacement, nor a need for one. The behaviour for selecting values is solid enough to make this option redundant.
• width: Gone and not required anymore. The menu will automatically be as wide as the input it completes, or wider, as the content requires. And you can always restrict with width using CSS.

And thats about it. If you're still looking for a particular replacement, take a look at the various events available, and study the use of the source-option within the various demos. If you still have a question, post on the Using jQuery UI forum. If you spot some mistake or see something that can be improved in this article, please let us know in the comments.

The jQuery UI 1.8 release brings along the new autocomplete widget. An autocomplete adds a list of suggestions to an input field, displayed and filtered while the user is typing. This could be attached to a search field, suggesting either search terms or just matching results for faster navigation. But what if there is a fixed list of options, usually implemented as a standard HTML select element, where the ability to filter would help users find the right value way faster?

That's a "combobox." A combobox works like a select, but also has an input field to filter the options by typing. jQuery UI 1.8 actually provides a sample implementation of a combobox as a demo. In this article, we'll look under the hood of the combobox demo, to explore both the combobox widget and the autocomplete widget that it uses.

Let's starts with the initial markup:

Nothing special there, just a label and a select element with a few options.

The code to apply the combobox widget to the select is quite simple, too:

Let's look at the code for this combobox widget. First, the full code, to give you an overview. We'll dig into the details step-by-step afterwards.

Let's break this down, piece by piece:

This defines a new widget, in the ui namespace (don't use this for your own widgets, it's reserved for jQuery UI widgets) and adds the only method, _create. This is the constructor method for jQuery UI widgets, and will be called only once. In versions prior to 1.8 it was called _init. The _init method still exists, but it is called each time you call .combobox() (with or without options). Keep in mind that our widget implementation is not complete, as it lacks the destroy method. It's just a demo.

Coming up next is the creation of an input element and applying the autocomplete to it, with data provided by the select element.

It starts with a few variable declarations: var self = this will be used inside callbacks below, where this will refer to something else. The var select references the select element on which the combobox gets applied. To replace the select with the text input, the select is hidden.

The selected and value variables are used to initialized the autocomplete with the current value of the select.

An input element is created from scratch, inserted after the select element into the DOM, and transformed into an autocomplete widget. All three autocomplete options are customized:

• delay specifies the amount of time to wait for displaying data between each key press, here set to zero as the data is local
• minLength is set to 0, too, so that a cursor-down or -up key press will display the autocomplete menu, even when nothing was entered.
• source provides the filtered data to display

Let's break down the source implementation:

There is a bit of matching and mapping involved here: At first, a regular expression object is defined, based on the entered term, escaped with the help of the $.ui.autocomplte.escapeRegex utility method. This regex gets reused in the function below. The response argument, a callback, gets called, to provide the data to display. The argument passed is the result of the call to select.find("option").map(callback). That finds all option elements within our original select, then maps each option to a different object, implemented in another callback passed to the map method.

This callback will return undefined, thereby removing an item, when a search term is present and the text of the option doesn't match the entered value. Otherwise (no term, or it matches), it'll return an object with three properties:

• label: based on the text of the option, with the matched term highlighted with some regexing (another example of a write-only regular expression)
• value: the unmodified text of the option, to be inserted into the text input field
• option: the option element itself, to update the select (via the selected-property) or to pass on in custom events

The label and value properties are expected by the autocomplete widget, the option property has an arbitrary name, used here only by the combobox widget.

Before, I mentioned that the combobox widget customizes all three autocomplete options, but there were actually five options specified. The fourth and fifth properties, select and change, are event. This is the select implementation:

The ui.item argument refers to the data we provided in the source option. Via the ui.item.option property we can update the underlying select to the selected item, as well as triggering a selected events for further customization of the combobox widget.

To cover the case where no selection is made, the change event is used:

Here the entered value is used to try and match a selection. If the value doesn't match anything, it'll get removed, and the underlying select is set to an empty value, too.

The next block customizes the _renderItem method of the underlying autocomplete. This is necessary to output the highlighting on each row, as autocomplete by default will escape any html.

And finally, the last block creates the button that opens the full list of options:

Another element is created on-the-fly. It gets tabIndex="-1" to take it out of the tab order, as it's mostly useful for mouse interactions. Keyboard interaction is already covered by the input element. It gets a title attribute to provide a tooltip and is inserted after the input element into the DOM. A call to .button() with some options together with a bit of class-mangling transforms the button into a Button widget that displays a down-arrow icon with rounded corners on the right (the input has rounded-corners on the left).

Finally a click event is bound to the button: If the autocomplete menu is already visible, it gets closed, otherwise the autocomplete's search method is called with an empty string as the argument, to search for all elements, independent of the current value within the input. As the input handles keyboard input, it gets focused. Having focus on the button would be useless or would require duplicate keyboard interaction that the input already supports.

And that's it! We can see that the autocomplete widget is flexible enough to allow all this with option customization, events, and calling a few methods. We don't have to "subclass" autocomplete (creating a new widget with the autocomplete as the parent prototype instead of $.widget). Instead, we can make the combobox mostly independent of any internal or private autocomplete methods. For the full experience and latest version, check out the combobox demo on the jQuery UI site.

• jQuery UI 1.6 is shaping up to be a rock-solid re-factoring of the entire library. With RC4 released just two days ago, the UI team have further cleaned up the API while providing a set of tools that are even more extensible and configurable than they were before.
• Better project management and greater transparency. Over the last year or so, Paul Bakaus has done much more than lead the development of jQuery UI. He has shaped and nurtured a team of top-notch JavaScript developers and has opened up a lot of the decision-making process to outside scrutiny. This bodes well for the direction of the project.
• Improved jQuery UI ThemeRoller. ThemeRoller, developed and designed by the folks at Filament Group, was already an amazingly useful and elegant complement to jQuery UI. But now it's even better, with a much-improved CSS framework and lighter CSS footprint, a slick default theme, a cool icon sprite set, and more configuration options. Also, it'll soon be easier than ever to create your own UI widgets that take advantage of the ThemeRoller — with upcoming tools, documentation, and tutorials for making your site "ThemeRoller-ready."
• Improved documentation and demos. The documentation wiki has undergone some significant updates in recent months, and the demos went through a complete overhaul in coordination with the 1.6rc4 release.
• More widespread adoption. As the API changes settle down and the core UI developers have more time to spend on providing more widgets and components, such as a spinner, menu, and colorpicker, more sites are sure to join the likes of WordPress in adopting jQuery UI.
• A new blog. While most of the details are still under wraps, a brand new weblog dedicated to learning jQuery UI, similar in quality and scope to Learning jQuery, will be online soon.

Update:

A very exciting CSS theming application was also released with jQuery UI 1.5, called ThemeRoller. ThemeRoller is an amazing way to customize the style and colors across all of the jQuery UI components. It comes with a few preset styles, as well as allowing you to create your own. Once you are done, it packages your theme into a zip file that contains all of the images and CSS you need.

Brief Overview of the jQuery UI Project

The jQuery UI project was originally created to bring you a set of "official" jQuery plugins. Mature components from the plugins repository were pulled together to form the first release of jQuery UI. But since each of these plugins had its own style, having been written by different authors, the first release of the library felt a bit cumbersome when packaged together. With that in mind, the focus of UI 1.5 was on achieving a coherent, standardized API to eliminate much of the differences between the components. Through much time and effort, many bugs and feature requests were addressed along the way as well.

Inside Look at jQuery UI Version 1.5

Before starting, I want to make sure you know where the jQuery UI Documentation is located. You may also want to head to the download page to grab the library for yourself. Note that the development bundle is the easiest to get started with.

First, let's start by including the necessary files for jQuery UI: jQuery latest js file, the Flora theme complete stylesheet, and the core UI file. Each of the components is built on top of these files. Here is how to include them:

You may want to download these files and put them on your own server, but this is just fine for our demonstration.

At this point you may include the jquery.ui.all.js script for testing, or include each of the components individually. Here are the components that we are using for this demo:

Activating Components

Each component has a constructor method, which is the component name. For instance, we can make a div draggable by using the draggable() method:

The component defaults can be overridden by passing in options to the main function. For instance, if we want to make the div drag only horizontally, we can set the axis option to "x" with the following code:

Likewise, the Accordion can be accessed the same way. Here we set a custom option to specify the accordion to slide on the mouseover event:

• Test 1
  Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
• Test 2
  Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam
  
• Test 3
  Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.

Some of the components, such as draggable and resizable, can even be combined:

This first makes the div draggable, then adds the resize handles to the div.

Now you should have what you need to start with each of the components! Head to the functional demos page to see in-depth examples of each of the components.

Looking at the Future of jQuery UI

With Paul Bakaus hired as (paid) full-time lead of jQuery UI, the project has been energized, charging forward by leaps and bounds. With an ever-growing set of UI components, jQuery UI's future is shaping up to be one of great promise.