Web Foundations
By Rebecca Goodwin

HTML5 Forms Explained

By Rebecca Goodwin

HTML5 web forms have introduced new form elements, input types, attributes, and other features. Many of these features we’ve been using in our interfaces for years: form validation, combo boxes, placeholder text, and the like. The difference is that where before we had to resort to JavaScript to create these behaviors, they’re now available directly in the browser; all you need to do is set an attribute in your markup to make them available.

HTML5 not only makes marking up forms easier on the developer, it’s also better for the user. With client-side validation being handled natively by the browser, there will be greater consistency across different sites, and many pages will load faster without all that redundant JavaScript.

HTML5 Form Attributes

For years, developers have written (or copied and pasted) snippets of JavaScript to validate the information users entered into form fields: what elements are required, what type of data is accepted, and so on. HTML5 provides us with several attributes that allow us to dictate what is an acceptable value, and inform the user of errors, all without the use of any JavaScript.

Browsers that support these HTML5 attributes will compare data entered by the user against regular expression patterns provided by the developer (you). Then they check to see if all required fields are indeed filled out, enable multiple values if allowed, and so on. Even better, including these attributes won’t harm older browsers; they’ll simply ignore the attributes they don’t understand. In fact, you can use these attributes and their values to power your scripting fallbacks, instead of hardcoding validation patterns into your JavaScript code, or adding superfluous classes to your markup.

Let’s go through each of the new attributes.

HTML5 New Form Input Types


The search input type (type="search") provides a search field — a one-line text input control for entering one or more search terms.

The spec states:
The difference between the text state and the search state is primarily stylistic: on platforms where search fields are distinguished from regular text fields, the search state might result in an appearance consistent with the platform’s search fields rather than appearing like a regular text field.

Many browsers style search inputs in a manner consistent with the browser or the operating system’s search boxes. Some browsers have added the ability to clear the input with the click of a mouse, by providing an x icon once text is entered into the field.

While you can still use type="text" for search fields, the new search type is a visual cue as to where the user needs to go to search the site, and provides an interface the user is accustomed to.

Since search, like all the new input types, appears as a regular text box in nonsupporting browsers, there’s no reason not to use it when appropriate.

Email Addresses

The email type (type="email") is, unsurprisingly, used for specifying one or more email addresses. It supports the Boolean multiple attribute, allowing for multiple, comma-separated email addresses.

If you change the input type from text to email you’ll notice no visible change in the user interface; the input still looks like a plain text field. However, there are differences behind the scenes.

The change becomes apparent if you’re using an iOS device. When you focus on the email field, the iPhone, iPad, and iPod will all display a keyboard optimized for email entry (with a shortcut key for the @ symbol).


The url input (type="url") is used for specifying a web address. Much like email, it will display as a normal text field. On many touch screens, the on-screen keyboard displayed will be optimized for web address entry, with a forward slash (/) and a “.com” shortcut key.

Telephone Numbers

For telephone numbers, use the tel input type (type="tel"). Unlike the url and email types, the tel type doesn’t enforce a particular syntax or pattern. Letters and numbers—indeed, any characters other than new lines or carriage returns—are valid. There’s a good reason for this: all over the world countries have different types of valid phone numbers, with various lengths and punctuation, so it would be impossible to specify a single format as standard. For example, in the USA, +1(415)555-1212 is just as well understood as 415.555.1212.

The number type (type="number") provides an input for entering a number. Usually, this is a “spinner” box, where you can either enter a number or click on the up or down arrows to select a number.

The number input has min and max attributes to specify the minimum and maximum values allowed. We highly recommend that you use these, otherwise the up and down arrows might lead to different (and very odd) values depending on the browser.

On many touchscreen devices, focusing on a number input type will bring up a number touch pad (rather than a full keyboard).


The range input type (type="range") displays a slider control in browsers that support it (currently Opera and WebKit). As with the number type, it allows the min, max, and step attributes. The difference between number and range, according to the spec, is that the exact value of the number is unimportant with range. It’s ideal for inputs where you want an imprecise number; for example, a customer satisfaction survey asking clients to rate aspects of the service they received.

The default value of a range is the midpoint of the slider—in other words, halfway between the minimum and the maximum.

The spec allows for a reversed slider (with values from right to left instead of from left to right) if the maximum specified is less than the minimum; however, currently no browsers support this.


The color input type (type="color") provides the user with a color picker—or at least it does in Opera (and, surprisingly, in the built-in browser on newer BlackBerry smartphones). The color picker should return a hexadecimal RGB color value, such as #FF3300.

Until this input type is fully supported, if you want to use a color input, provide placeholder text indicating that a hexadecimal RGB color format is required, and use the pattern attribute to restrict the entry to only valid hexadecimal color values.

Dates and Times

There are several new date and time input types, including date, datetime, datetime-local, month, time, and week. All date and time inputs accept data formatted according to the ISO 8601 standard.

This comprises the date (year, month, and day), but no time; for example, 2004-06-24.
Only includes the year and month; for example, 2012-12.
This covers the year and week number (from 1 to 52); for example, 2011-W01 or 2012-W52.
A time of day, using the military format (24-hour clock); for example, 22:00 instead of 10.00 p.m.
This includes both the date and time, separated by a “T”, and followed by either a “Z” to represent UTC (Coordinated Universal Time), or by a time zone specified with a + or – character. For example, “2011-03-17T10:45-5:00” represents 10:45am on the 17th of March, 2011, in the UTC minus 5 hours time zone (Eastern Standard Time).
Identical to datetime, except that it omits the time zone.

The most commonly used of these types is date. The specifications call for the browser to display a date control, yet at the time of writing, only Opera does this by providing a calendar control.

In Conclusion

As support for HTML5 input elements and attributes grows, sites will require less and less JavaScript for client-side validation and user interface enhancements, while browsers handle most of the heavy lifting. Legacy user agents are likely to stick around for the foreseeable future, but there is no reason to avoid moving forward and using HTML5 web forms, with appropriate polyfills and fallbacks filling the gaps where required.

If you want to take the full course and get all the information you need, check out the learnable.com course HTML5 & CSS3 for the Real World.

Looking for something specific – Sitepoint offers a range of free online tutorials

This is an excerpt from the Sitepoint book HTML5 & CSS3 for the Real World by Alexis Goldstein, Louis Lazaris, and Estelle Weyl.

No Reader comments