Everyone who uses the web is familiar with the delivery of “autosuggest”, from Google’s initial offering (now replaced by the Instant Search algorithm) to infinitely varied interfaces on sites and mobile devices.

The purpose behind every instantiation of autosuggest is always the same: to anticipate and guide the user. No-one wants to spend time laboriously typing in an entire product or place name into a text box: if programming can accurately predict what a user intends to write from a few keystrokes, so much the better.

Traditionally this has been achieved through the use of JavaScript, sometimes with AJAX: JQuery UI has an autocomplete function, for example. But as with many things, HTML5 is building that capability natively into the browser, in this case via the datalist element.

The creation of a datalist is simplicity itself. In this example, I’ll use a portion of code from the site I created over the holiday season, tipster.io, which dynamically suggests country names as the user types into a search field:

<form>
	<label for="country">Enter a country:</label>
	<input type="search" maxlength="20" size="22" autocomplete="off" spellcheck name="country" id="country" list="countries" placeholder="Japan">
	<datalist id="countries">
		<option value="Albania">
		<option value="Argentina">
		<option value="Australia">
		<option value="Austria">
	…
	</datalist>
	<input type="submit" value="Go">
</form>

Technically, a datalist could be connected to any type of text input: all that’s required is that you pair the list attribute on the input element with the value of the id for the corresponding datalist. In the example above I’ve turned off autocomplete so that a user’s browser won’t attempt to fill the field with its own guesses at the text, and turned on spellcheck so that misspelled country names will be pointed out to the user.

You can try the example at the top of this article, or play with the more fully-featured version at tipster.io. There are a few important points to note before deciding to use datalist in your own site:

• While support for datalist in desktop browsers is good, mobile devices do not support the element yet. This is probably due to the consideration software engineers are giving to balance a site’s use of autosuggest with the mobile space’s OS-specific use of the same feature.
• If the client does not support the datalist or search tags, the input will fall back to being a standard text interface. In that case, you could use a JavaScript polyfill, possibly combined with Modernizr for feature detection, to provide an equivalent interface. A few examples: Chris Coiyer’s Relevant Dropdrowns, and this one.
• As with the search element, datalist does not magically “make search happen” on a website. You will have to put in the time and code into building search features.
• datalist does not respond to common spelling mistakes or incorrect letter combinations in its suggestions. Instead, your backend code should route around anticipated errors.
• The element is best used as pure HTML5 when the possible solution space is small, known, and unchanging: a country list is a good example. If the number of possible terms is high or changes frequently, you’ll need to fall back to an AJAX-like approach that alters the datalist content dynamically.
• datalist should increasingly be considered as a very effective alternate to the traditional <select> element: rather than opening up and scrolling through a long list of options, datalist can be used to dynamically deliver a limited range of possibilities to the user.

Enjoy this piece? I invite you to follow me at twitter.com/dudleystorey to learn more.