Understanding HTML5 intelligent forms – Part 1: New input elements

Forms are everywhere on the web. They're essential for gathering information through surveys, feedback pages, blog comments, and shopping carts. Thanks to HTML5, online forms are about to get a whole lot better.

HTML5 form features fall into two categories: dedicated input elements for data such as email addresses and numbers, and new attributes that allow you to specify whether an item is required, minimum and maximum values, and so on. The latest versions of browsers have already begun implementing many of these features. Once they're fully implemented, they'll eliminate the need to use JavaScript for client-side form validation (although you should still validate user input on the server for security reasons). And the good news is that you can start implementing these features right away, because they have been designed to be backwards compatible with HTML 4.01 and XHTML 1.0. Older browsers that don't recognize the new input elements simply treat them as ordinary text input fields. So, with one minor exception (the range input type), you can use HTML5 form features safely in all browsers.

In this first part of a two-part tutorial, I'll describe the new input elements and the <datalist> element, which allows you to suggest options for a text input field. In Part 2, you'll learn about the HTML5 form attributes.

Figure 1 shows a simple online form that contains a text field, check box, radio (or option) buttons, file upload field, and a Submit button.

The underlying HTML markup for this form looks like this (see also html4_input.html in the example files that accompany this tutorial):

The notable feature of this form is that every element uses the <input> tag. What changes the look and behavior of each element is its type attribute. So, instead of having a dedicated tag for check boxes, for example, and another for radio buttons, the same HTML tag is used for a variety of purposes. Of course, other tags, such as <select> and <textarea> are also used in forms, but the <input> tag is the most versatile. What's more, the default value of the type attribute is text . So, if the attribute is missing—or the browser doesn't recognize it—the form displays a simple text field.

HTML5 takes advantage of this default behavior to define no fewer than 13 new form elements by expanding the range of accepted values for the type attribute. Browsers that understand the new values handle form input according to the HTML5 specification. Older browsers simply display standard text fields. It's a win-win situation, meaning that you can start incorporating the new input types in your forms right now. Table 1 lists the specialized text input types, of which there are six. I'll deal later with the remaining types, which are dedicated to dates and time, and a number slider.

Table 1. HTML5 specialized text input types

To add one of these new input types to a form, you simply create a text input field and change its type attribute in the HTML markup. Code hints in Dreamweaver CS5.5 support all HTML5 input types (see Figure 2).

You can also change the type attribute by highlighting the <input> tag, and selecting the appropriate value from the pop-up menu in the General category of the Tag Inspector panel (Window > Tag Inspector), as shown in Figure 3.

A sample of each new input type listed in Table 1 is in html5_input.html in the example files that accompany this tutorial. The following sections describe each one briefly.

Creating a search field

Setting the type attribute of an <input> tag to search is mainly of cosmetic value. It doesn't automatically create a search field. As with all form elements, you still need to code the server-side logic yourself or use a third-party script. Most browsers simply display a search field as a normal text field. However, Safari and Chrome on Mac OS X automatically add rounded corners to match the operating system's standard look (see Figure 4).

Creating a dedicated field for phone numbers

There's no internationally agreed format for telephone numbers, so setting the type attribute to tel doesn't appear all that useful—until you test it on a smartphone or tablet, that is. As Figure 5 shows, tapping a tel input field on an iPod touch, iPhone, or similar device brings up the phone keypad. This not only makes it a lot easier to enter the phone number, but it also prevents invalid characters from being entered on a mobile device.

Desktop browsers currently don't treat tel input fields differently from ordinary text fields. However, if you want to enforce a particular format for a telephone number, you can use the pattern attribute, which you'll learn about in Part 2 of this two-part tutorial.

Creating a URL input field

Setting the type attribute to url also brings up the appropriate keypad on modern mobile devices. The most recent versions of desktop browsers, apart from Internet Explorer (IE) 9 and Safari 5.1, automatically validate the user input when the form is submitted. However, in Firefox 5, Chrome 13, and IE 10 Preview 2 the validation is stricter than you might expect. As Figure 6 shows, "www.adobe.com" is rejected as not being a valid URL.

Firefox 5, Chrome 13, and IE 10 Preview 2 all insist on a fully qualified URL beginning with http://. On the other hand, Opera 11.50 automatically inserts the http:// for you if it has been omitted. However, Opera doesn't perform any other validation. For example, if you enter "adobe" in the field, it simply converts it to "http://adobe" and submits it, even though it's not the correct format for a URL.

Clearly, there's some way to go before browsers handle URL fields in a consistent, user-friendly way.

Creating an email input field

Support for the email input type is similar to that for URLs. If you set the type attribute to email, mobile devices display the appropriate keypad when the user taps the field. On a desktop computer, Firefox 5, Chrome 13, IE 10 Preview 2, and Opera 11.50 prevent the form from being submitted if the input contains illegal characters or doesn't include an @ mark.

A really useful feature of the email input type is that it prevents users from attempting to stuff the field with multiple email addresses. Only a single address is permitted unless you also set the multiple attribute on the <input> tag like this:

Creating a number field

Setting the type attribute to number creates a field intended for numerical input. On iOS, tapping the field displays a numeric keypad, but you can also switch to alphabetic input. On Android, however, the keypad permits only numbers and a limited range of punctuation characters.

The latest versions of all mainstream desktop browsers, except IE and Firefox 5, display a number spin box similar to Figure 7. Clicking the up arrow to the right of the box increases the number in the field. Clicking the down arrow reduces the number.

Currently, browsers don't check whether the submitted value is actually a number, so a user could type "ten" in the field, and the form would be submitted without problem. However, you can enforce the use of a number with the pattern attribute (see Part 2).

Adding a color picker

Currently, the only browser that supports the color type is Opera. It displays a color box, which expands to display a set of common color swatches (see Figure 8).

Clicking the Other button below the swatches opens a full color picker that lets you select and store custom colors. The selected color is transmitted as a hexadecimal color value when the form is submitted.

What happens in older browsers

As mentioned earlier, the new HTML5 input elements have been designed to be backward compatible. So, if an older—or even relatively modern—browser doesn't recognize the new type attributes, it simply displays an ordinary text field. Figure 9 shows html5_input.html in IE 9.

The form remains perfectly usable in IE 9 and older browsers even though they have no support for HTML5 form elements.

Six of the new input types are dedicated to date- and time-related values. Support for these input fields is still patchy. Currently, iOS, Android, Firefox 5, and IE 10 Preview 2 display ordinary text input fields. Chrome and Safari treat them like number spin boxes, increasing and decreasing the value depending on whether you click the up or down arrow. Opera and BlackBerry offer the most user-friendly support with calendar pop-ups. Figure 10 shows what happens when you put the focus in a date field in Opera 11.50. It displays a navigable calendar that defaults to the current date.

The latest versions of BlackBerry devices offer a similar experience. Figure 11 shows what happens when you tap a date field in a BlackBerry PlayBook.

In spite of their user-friendly date pickers, what comes as a surprise is the format of the date they enter into the form field. The date shown in Figure 11 is inserted as 2011-08-03—in other words, in the order year, month, and date. This is not an arbitrary decision, but is the format mandated by the World Wide Web Commission (W3C), which is responsible for drawing up the HTML5 specification.

The YYYY-MM-DD format has been chosen because it's the way the International Organization for Standardization (ISO) recommends that dates should be presented. Table 2 shows all date- and time-related input types in the HTML5 specification together with the required format.

Table 2. HTML5 date- and time-related input types

The W3C's choice of formats is intended to solve the vexed problem of differing date formats around the world. They work fine in a technical environment, but—with the exception of the time input type—are likely to confuse nontechnical users. Figure 12 shows actual examples of the official formats as rendered by Chrome 13.

Local customs regarding date formats are so deeply ingrained that I think the HTML5 date-related input types will find little practical application unless the specification is amended to permit alternative formats. Another possibility is that browsers could offer the option to display the date in a local format, but use the official format when the form is submitted.

In the meantime, I think the best approach is to provide separate text input fields or <select> menus for the month, date, and year. Alternatively, use a single text input field with a configurable JavaScript widget, such as the jQuery UI Datepicker. In Part 2 of this tutorial, I'll also show you how to use the pattern attribute with a text input field to enforce a specific date format in HTML5-compliant browsers.

The final new type attribute for the <input> tag is range , which creates a slider that allows the user to select a numeric value. Currently, this input type is supported by iOS, Safari, Chrome, and Opera. With the exception of Android, other browsers display an ordinary text input field. Unfortunately, in my experiments, Android completely ignores the range type, severely limiting its usefulness. However, it's an interesting input type, so I'll describe it in full.

According to the specification, the range input type is intended to be used when the exact value is not important. The reason for this becomes clear when you see a default slider in an HTML5-compliant browser. Figure 13 shows a slider in Opera (you can test it yourself in slider.html in the example files).

Although Opera displays a scale below the slider, other browsers don't, and there's no indication of the selected value. By default, the range type allows the user to select a value between 0 and 100, and is initially set to the halfway point—in other words, 50. Moving the slider in either direction increases or decreases the selected value in steps of 1.

On its own, the range input type is a very crude tool. However, with a little extra code, it becomes much more versatile. By setting the min, max, and step attributes, you can change the default range and incremental value (only whole numbers can be used). For example, the following HTML markup sets a range of 0–25 in steps of 5 (0, 5, 10, and so on):

To set the initial value to zero, just add the value attribute like this:

As Figure 14 shows, the slider is automatically set to the far left of the track, and Opera adjusts the scale to indicate the new range of selectable values (the code is in slider2.html in the example files).

Even though Chrome and Safari don't display a scale, if you test slider2.html in either of those browsers, you'll see that the slider stops only at positions roughly equivalent to 0, 5, 10, and so on. Still, it would be much better to show users what value they have selected. You can do so with the HTML5 <output> tag and some very simple JavaScript, as described in the next section.

Displaying the slider's value

The following instructions show how to display the value selected by an HTML5 range input element.

1. Open slider2.html in the example files. The HTML markup for the form looks like this:

2. In Code view, position the insertion point immediately after the <input> tag and add an opening and closing pair of <output> tags like this (if you're using Dreamweaver CS5.5, code hints will autocomplete the tags):

3. In the opening <output> tag, give the element a unique name, such as display_rate:

4. Link the <output> and <input> elements using the for attribute and setting its value to the <input> element's ID like this:

5. To display the value selected by the slider, you need to add an onchange handler to the slider. Add the following code inside the <input> tag:

In JavaScript, this represents the target of the current event. So, whenever the slider is moved, this.value contains the slider's selected value. Because the name of the <output> element is display_rate, this code sets the value of the <output> element to the same value as the slider.

The complete code for the <input> and <output> elements should now look like this (the code is also in slider_output.html in the example files):

6. Save the page, and load it into a browser that supports the range input type (currently Chrome, Safari, or Opera). The <output> element doesn't have an initial value, so the slider should look the same as Figure 14.
7. Move the slider. The selected value should appear alongside, as shown in Figure 15.

Note: According to the HTML5 specification, the default value of an <output> element must initially be an empty string—in other words, nothing. To change the default, you need to use JavaScript to set the element's defaultValue property when the page loads. This is currently supported only by Chrome and Safari. In practice, current browsers allow you to set the initial value by inserting a number between the opening and closing <output> tags. The number updates automatically when the slider is moved. However, this has the unfortunate side effect of displaying an unchanging value alongside the text field of the range input element.

A really useful addition to HTML5 forms is the <datalist> element, which is currently supported only by Opera. It associates a set of predefined options with a text input field, allowing you to create an editable <select> menu. Figure 16 shows a simple example of a datalist in Opera.

When the focus is in the text field, the datalist displays a set of options for the user to choose from. If one is selected, it's entered in the field. However, the user is free to enter a completely different value. For example, Princess Leia could type "Princess" in the Title field rather than settling for plain Ms.

The HTML markup for a datalist is very simple. The example shown in Figure 16 looks like this (it's also in datalist.html in the example files):

You associate a text input field with a datalist by adding the list attribute to the <input> tag and setting its value to the ID of the <datalist> element—in this case, titlelist.

The <datalist> element serves as a wrapper for a set of <option> tags, which you probably recognize from <select> menus. An important difference is that a datalist requires the value attribute to be present in the <option> tag. Unlike a <select> menu, <datalist> won't display values nested between opening and closing tags. For example, the following won't work in a <datalist>:

<option>Mr.</option>

It must be like this:

<option value="Mr.">

Although the <datalist> element isn't yet widely supported, you can safely use it in existing forms. Browsers that don't recognize it simply display the ordinary text input field. But as soon as browser support catches up, visitors to your sites benefit from the list of suggested options.

That concludes Part 1 of this overview of HTML5 forms, describing the 13 new input types and the <datalist> element. In Part 2, you'll learn about the new form attributes, such as autocomplete, autofocus, and required.