10 August 2011
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.
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):
<form method="post" enctype="multipart/form-data" name="form1"> <p> <label for="name">Name:</label> <input type="text" name="name" id="name"> </p> <p> <input type="checkbox" name="terms" id="terms"> <label for="terms">I have read the terms and conditions</label> </p> <p> <label> <input type="radio" name="gender" value="f" id="gender_0"> Female</label> <br> <label> <input type="radio" name="gender" value="m" id="gender_1">Male</label> </p> <p> <label for="file">Upload file:</label> <input type="file" name="file" id="file"> </p> <p> <input type="submit" name="send" id="send" value="Submit"> </p> </form>
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
<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
Single-line text field for phone number
Single-line text field for URL
Single-line text field for one or more email addresses
Single-line text field or number stepper
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.
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).
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.
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.
Support for the
type attribute to
A really useful feature of the
multiple attribute on the
<input> tag like this:
<input type="email" name="email" id="email" multiple>
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).
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.
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.
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
Year (4 digits), month (2 digits), and date (2 digits), each value separated by hyphens.
UTC (Universal Coordinated Time) date and time. The date is expressed in the same format as
The date and local time expressed in the same format as
The year (4 digits) and month (2 digits separated by a hyphen.
The year (4 digits) followed by a hyphen, the letter W, and the week number (2 digits).
Time expressed in the 24-hour clock with optional seconds and milliseconds. Hours, minutes, and seconds are separated by colons.
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
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
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):
<input type="range" name="rating" id="rating" min="0" max="25" step="5">
To set the initial value to zero, just add the
value attribute like this:
<input type="range" name="rating" id="rating" min="0" max="25" step="5" value="0">
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
The following instructions show how to display the value selected by an HTML5
range input element.
<form method="post" name="form1"> <p> <label for="rating">Rating:</label> <input type="range" name="rating" id="rating" min="0" max="25" step="5" value="0"> </p> </form>
<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):
<input type="range" name="rating" id="rating" min="0" max="25" step="5" value="0"><output></output>
<output>tag, give the element a unique name, such as
<input>elements using the
forattribute and setting its value to the
<input>element's ID like this:
<output name="display_rate" for="rating"></output>
onchangehandler to the slider. Add the following code inside the
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
<output> elements should now look like this (the code is also in slider_output.html in the example files):
<input type="range" name="rating" id="rating" min="0" max="25" step="5" value="0" onchange="display_rate.value=this.value"><output name="display_rate" for="rating"></output>
rangeinput 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.
Note: According to the HTML5 specification, the default value of an
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):
<input type="text" name="title" id="title" list="titlelist"> <datalist id="titlelist"> <option value="Mr."> <option value="Mrs."> <option value="Ms."> </datalist>
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,
<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
<datalist> won't display values nested between opening and closing tags. For example, the following won't work in a
It must be like this:
<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
This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License. Permissions beyond the scope of this license, pertaining to the examples of code included within this work are available at Adobe.