Understanding HTML5 intelligent forms – Part 2: New form attributes

Validating user input in online forms needs to be done in two places—in the browser to prevent the form from being submitted with insufficient or invalid data, and on the server to filter out potential attacks. You'll still need to write your own server-side processing script or use a third-party one, but HTML5 is assuming most of the burden of validating user input before submitting it to the server. In Part 1 of this two-part tutorial series, I described the specialized input types for such values such as phone numbers, email addresses, and dates. In this second part, you'll learn about new form attributes that allow you to specify required fields, minimum and maximum values, and so on. You'll also learn how to ensure that ZIP codes, phone numbers, and similar values conform to a set format.

To demonstrate how various HTML5 attributes work, the files in html5_forms_pt2.zip contain simple forms, such as this one in on-off_01.html:

The type attribute of the first <input> tag uses the default text value, which creates an ordinary text input field. The second and third fields use the new url and email types. Figure 1 shows what the form looks like in a browser.

As explained in Part 1, older browsers that don't understand HTML5 form elements treat them as ordinary text input fields. Modern HTML5-compliant browsers check that the data matches the specified type before allowing the form to be submitted.

Use the example files in a variety of browsers to see the level of support they offer. The forms don't send the data anywhere. Processing form data is a huge subject beyond the scope of this tutorial, but clicking the submit button simulates what happens when a form is submitted. If the input fields clear, it indicates that the data was submitted successfully. If the data is invalid, modern browsers display an error message, preventing the form from being submitted until the error is corrected.

HTML5 defines several Boolean attributes—ones that represent true or false—for forms, namely:

• autofocus
• required
• multiple
• formnovalidate
• novalidate

Adding one of these attributes to a tag turns the feature on. Leaving it out (or removing it programmatically) turns the feature off. Closely related to these Boolean attributes is autocomplete , which is on by default. To turn it off, you need to add it to a tag and explicitly set its value.

Automatically setting the focus in a field

As a courtesy to the user, it's a good idea to set the focus in the first field for many forms. Previously, the only way to do this has been with JavaScript. With HTML5, just add the autofocus attribute to the <input> tag like this (on-off_02.html):

If you load the page into a modern browser, the cursor is automatically inserted in the field. Most browsers also highlight the field to draw the user's attention, as shown in Figure 2.

Only one field can have focus at any given time, so you should use autofocus only once in a form. It works well for login forms and pages that are solely dedicated to filling in a form. But you probably shouldn't use it for a search field that's incidental to the main content.

Note: If you're using XHTML-style markup, you need to set the value of autofocus and other Boolean attributes to the same value as the attribute name like this: autofocus="autofocus" .

Making fields required

Making fields required is just as easy. Simply add the required attribute to the <input> tag like this:

If you attempt to submit the form without entering a value into the field, browsers that recognize the required attribute will prevent you from doing so, as Figure 3 shows (you can test it in on-off_03.html).

In on-off_04.html, the required attribute has been added to the name and email fields producing the result shown in Figure 4.

All browsers except Internet Explorer (IE) 6 support attribute selectors. If you still need to support IE 6, you can hide the paragraph at the top of the form in IE 6 using a class and an IE conditional comment setting the class's display property to none like this:

Load on-off_04.html into different browsers, and try submitting the form without entering a value. Among modern browsers, IE 9 and Safari 5.1 are the only ones that submit the required fields without validation. Chrome and Opera check only the first invalid field. However, Firefox 5 and IE 10 Preview 2 not only display an error message for the first field, but also outline both invalid fields in red (see Figure 5).

Allowing multiple values

The multiple attribute isn't new to HTML5, but its role has been expanded. Previously, its use was restricted to <select> elements, allowing you to convert a drop-down menu into a multiple-selection list. In HTML5, you can use it with other form fields to permit the submission of multiple values where normally only one would be accepted. In practice, this means with file upload and email fields.

The multiple attribute on file upload fields has been supported since Firefox 3.6, Safari 4, Chrome 4, and Opera 10. It's also supported by IE 10 Preview 2. Testing support for file upload fields requires a server-side technology, such as PHP or ColdFusion, which is beyond the scope of this tutorial. However, you can easily test email fields.

1. Load on-off_05.html into the latest version of Firefox, Chrome, or Opera. (Safari 5.1 and IE 9 don't support the email input type).
2. Enter two email addresses separated by a comma in the Email field, and click Submit. You should see an error message similar to Figure 6. The error message would be more helpful if it explained that multiple addresses are not permitted, but the form won't be submitted until you enter only a single address.

3. Edit the HTML markup to add the multiple attribute to the <input> tag like this (or use on-off_06.html):

4. Save the page and reload it in your browser. Then enter two email addresses separated by a comma.
5. When you click submit, what happens depends on the browser and the exact format that you used.

If there was no space between the comma and the addresses, all three browsers should accept the addresses.

If there was a space between the comma and the addresses, Firefox and Opera accept the addresses, but Chrome 13 displays the error message shown in Figure 7.

This is likely to confuse many users because it fails to explain that the problem is the space after the comma.

6. Remove the space after the comma, and Chrome should now accept the multiple addresses.
7. Try using a semicolon between the email addresses. This time the Chrome error message makes sense, because it tells you about the need to use a comma as the separator. The error messages in Firefox and Opera are less helpful, because they simply tell you to enter a (valid) email address.

IE 10 Preview 2 behaves the same way as Firefox and Opera in that it accepts a space after the comma and rejects any other separator without explaining why.

Although the error messages with multiple email fields can be confusing, the main advantage of the HTML5 email input type is the way it rejects the submission of multiple addresses unless you specifically add the multiple attribute to the <input> tag. This is a safeguard against casual spammers. Unfortunately, it's very easy for the determined spammer to get around this restriction, so you still need to validate user data on the server.

Turning off autocompletion

Most browsers try to help users by suggesting values that have previously been entered in the same form or in fields with common names, such as address or email. For example, Safari displays a list of recent values entered in an email field, (see as Figure 8) shows.

Most of the time, this behavior is welcome, but allowing the browser to autocomplete certain fields, such as username, password, or credit card number can be insecure. HTML5 gives you control with the autocomplete attribute, which can be applied to a whole form or to individual input elements. By default, autocomplete is turned on, so you don't need to do anything if you're happy for the browser to make suggestions.

To turn off autocompletion for an entire form, add autocomplete="off" to the opening <form> tag. To turn off autocompletion for an individual element, add autocomplete="off" to the element's tag. For example, the email field in on-off_07.html looks like this:

This turns off autocompletion for the email field, but leaves the default behavior for other fields.

Note: In my experiments, adding autocomplete="off" to an opening form tag is one ring to rule them all. You cannot override it for an individual element by adding autocomplete="on" to the element's tag.

Turning off automatic validation

Validating user input is important, so why would you want to turn off HTML5's automatic validation? There are several reasons:

• Many of your site's visitors still use old browsers, and you want to apply your own custom validation to everyone.
• You want to provide an option for users to save a draft before submitting the form.
• You want to test your server-side validation without the browser validation preventing the form from being submitted.

Whatever your reason for wanting to turn off automatic validation, there are two ways to do so:

• Add the novalidate attribute to the opening <form> tag.
• Add the formnovalidate attribute to the submit button's tag.

Why two different attributes? Using novalidate in the opening <form> tag is basically a catch-all way of preventing the form from being validated when it's submitted. The formnovalidate attribute gives you a finer degree of control because it applies only when that particular button is clicked. For example, you could have separate buttons to save a draft and to submit the data like this:

You can test this in on-off_08.html. Leave one of the required fields empty, and click the Save Draft button. The other fields clear, because automatic validation is skipped (it's a dummy form, so no data is actually saved). Try it again with the Submit button. This time, the browser does the normal validation checks and reports that the required field needs to be filled in.

In HTML 4.01 and XHTML 1.0, the maxlength attribute sets the maximum number of characters permitted in a text or password field. HTML5 extends its use to the following new input types:

• search
• tel
• email
• url

Setting the maximum number of characters in a text area

More significantly, perhaps, you can now also use maxlength to limit the number of characters in a <textarea> element. Currently, this is supported by the latest versions of Firefox, Chrome, and Safari. Once the limit is reached, the browser stops any further characters from being entered. You can test this in textarea-maxlength.html, which limits the number of permitted characters to 50 like this:

Note also that the <textarea> tag no longer requires the rows and columns attributes. Use CSS to set the text area's width and height.

Setting minimum and maximum values for numeric fields

When using the HTML5 number and range input types, you can specify the minimum and maximum acceptable values with the min and max attributes. You can also specify the size of the increment between values using the step attribute. The values for min , max , and step must be numbers (integers or floating-point).

The markup in min-max_01.html sets the permitted range of values to 1–4 like this:

The step attribute is omitted, so the default value of 1 is used. If you load the page into a browser that supports the number type (currently Safari, Chrome, or Opera), clicking the up and down arrows on the right of the input field displays only whole numbers between 1 and 4. You can type an out-of-range number directly into the field, but you get an error message as shown in Figure 9 when you click the submit button.

You need to be careful when using a floating-point number for step because of rounding errors caused by floating-point values. Opera automatically adjusts the value to the same number of decimal places as step , but Safari and Chrome use the raw number generated by the computer. To demonstrate the difference, min-max_02.html contains two sliders designed to generate a value between 0 and 1 in increments of 0.1. The HTML markup looks like this:

Figure 10 shows what happens when both sliders are set to 0.3 in Safari.

Strictly speaking, the rounding error is not a problem because the HTML5 specification says the range input type is intended for situations where a precise value is not important. However, if you need to display the value onscreen, you need to use the JavaScript parseFloat() method to convert it to a number, and then set the number of decimal places with toFixed() . The onchange handler in the second slider rounds the selected value like this:

Note: See Part 1 of this tutorial series for an explanation of the code used to display the output of an HTML5 slider.

Setting minimum and maximum ranges for dates and times

The min , max , and step attributes can also be used to set a permitted range of dates or times. However, the HTML5 date- and time-related input types accept only values that conform to formats that are more suited to a technical environment (see Table 2 in Part 1 of this tutorial).

The code in min-max_03.html limits the range of dates to between January 1, 2011 and December 31, 2015 like this:

The value of step has been set to 10, which further limits the choice of dates to every tenth day. In Safari and Chrome, clicking the up arrow inserts tomorrow's date (or the upper limit if the range has been exceeded). Clicking the down arrow inserts the date from 10 days ago. If you keep clicking, the date increases in steps of 10 days until you reach the end of the range.

In Opera, the calendar opens with dates in 10-day increments calculated from tomorrow's date highlighted in bold type. You can use the calendar's navigation arrows to move to different months or years within the specified range, but only highlighted dates can be selected (see Figure 11).

The value of step affects only the smallest unit. In the case of date , the increment is calculated in days. You cannot set date to increment one month at a time.

When used with time-related input elements, specifiying a value for step forces the field to display seconds as well as hours and minutes. The step attribute can also be set to the case-insensitive keyword any . In Safari and Chrome, using step="any" in a time input element sets the current time to the closest millisecond. Figure 12 shows the output in Chrome of the following time input elements after clicking the down arrow of each field in turn (the code is in min-max_04.html):

The first time element doesn't use step , so it displays only hours and minutes. Clicking the up or down arrow increases or decreases the value one minute at a time. In the second one, step is set to 10, so it displays hours, minutes, and seconds, which can be adjusted in increments of ten seconds. The final field uses step="any" , which inserts the current time to the closest millisecond. Clicking the up or down arrow has no effect. The value is fixed.

Instead of inserting the current time, Opera defaults to 12:00. Setting step to a numeric value displays seconds in the same way as Safari and Chrome, but step="any" has no effect; Opera displays only hours and minutes.

Many online forms help users by displaying hints inside text fields, usually in light gray. When the field has focus, the hint disappears. Previously, you needed to code everything in JavaScript. Not any more. With HTML5, you just add the placeholder attribute to the <input> tag and set its value to whatever you want to appear as the hint. Figure 13 shows the output of the following code in placeholder.html:

All browsers except IE support placeholder—and it's coming in IE 10.

Displaying hints is all very fine, but it's not much use unless you can check whether the user has entered the data in the correct format. Thanks to the pattern attribute, you can. The only snag is that the pattern needs to be a regular expression (regex). Building regular expressions isn't easy, but it's a vital skill for working with many web-related languages. You can learn more about regexes in my two-part tutorial Using regular expressions. There are also online repositories, such as the one at http://regexlib.com, where you can find regular expressions that have been tried and tested by others.

When using the pattern attribute, the following restrictions apply:

• The input must match the regex completely. Partial matches are not allowed.
• The ^ and $ anchors for the beginning and end of the pattern are automatically implied.
• The regex should not be enclosed in delimiters, such as forward slashes.
• You cannot use modifiers, such as i to perform a case-insensitive match.

The HTML5 specification also recommends including a description of the regex in the title attribute. Browsers use this as part of the error message if the input fails validation.

The code in pattern.html includes regular expressions for a five-digit zip code and a date formatted as MM/DD/YYYY :

Figure 14 shows what happens when Santa Claus enters his arrival date using the European DD/MM/YYYY format (after all, he comes from Lappland).

Note: A regex only matches a pattern. It doesn't check whether a date is valid. Nor can it distinguish between American- and European-style dates when both month and date are less than 12. For example, 07/04/2011 could mean either July 4 to an American or 7 April to a European, but it would still be accepted by the regex.

The regex for DD/MM/YYYY looks like this:

The pattern attribute is supported by the latest versions of all browsers, except Safari 5.1 and IE 9 (but it's supported by IE 10 Preview 2).

Earlier, I demonstrated the use of formnovalidate to turn off automatic validation when a particular Submit button is clicked. Closely related to this attribute are four others, which override the form's defaults:

• formaction overrides the action attribute
• formenctype overrides the enctype attribute
• formmethod overrides the method attribute
• formtarget overrides the target attribute

Adding these attributes to a submit button causes the button to override the value of the equivalent attribute in the opening <form> tag—or the default value if it's not defined in the opening tag. For example, if the method attribute in the opening <form> tag is set to post , you can use formmethod="get" to override it when a specific button is clicked.

To demonstrate how this works, the form in overrides.html looks like this:

The default settings in the opening <form> tag send the data to submit.html by the post method for processing. However, the form has two submit buttons.

• If you click Save Draft, the formnovalidate attribute turns off validation and the formaction attribute diverts the data to draft.html for processing. The <input> tag contains no other overrides, so the form is submitted by the post method, as specified in the opening <form> tag.
• On the other hand, the second button uses the formmethod attribute to override the post method and resets it to get . The <input> tag contains no other overrides, so the form is validated before being sent to the default submit.html for processing.

You can see the principle behind how this works by loading overrides.html into the latest version of Chrome, Firefox, Opera, or Safari. Clicking the buttons shows the different ways the form reacts by taking you to dummy processing pages.

1. Click Save Draft without entering any values into the text input fields. You should be taken directly to draft.html.
2. Check the URL in the address bar. There's no query string attached to it. The form data has been sent by the post method. (Even when all fields are empty, the form still submits their names and name of the submit button.)
3. Click the browser Back button to return to overrides.html.
4. This time, click Submit without entering any values. The form is not submitted and you're warned about the required fields.
5. Enter values in the Name and Email fields, and click Submit. This time you're taken to submit.html.
6. Check the browser address bar. The data you entered in the form has been submitted by the get method, and is attached to the URL as a query string (see Figure 15).

The ability to override the default form behaviors is an extremely powerful addition to HTML5. Unfortunately, it's not supported by Internet Explorer until IE 10. This means, in effect, that you won't be able to use these overrides for many years unless you're designing a form for an intranet where you know that everyone will be using a compliant browser. Shame, really.

In HTML 4.01 and XHTML 1.0, all form elements must be nested inside the opening and closing <form> tags. However, in HTML5 you can put a form element anywhere you like and associate it with a form using the new form attribute and setting it to the form's ID. For example, this is perfectly legitimate in HTML5:

The problem, as always, is lack of support. Until the form attribute is supported by all browsers in current use, you need to keep all form elements nested within the <form> tags.

Another important HTML5 form attribute is list , which associates a <datalist> element with an <input> field. This was described in Part 1 of this tutorial series.

One minor change is that you can now use the height and width attributes on an <input> element that uses an image as a button ( type="image" ).

If you have managed to survive this far, you'll realize that HTML5 introduces many new features designed to make online forms more intelligent. Unfortunately, the date- and time-related input elements aren't very user-friendly. Neverthless, the prospect of creating self-validating forms is appealing. The big question is when can you start using these new features. My personal view is that you can—and should—start using them now, with the exception of the form , formaction , formenctype , formmethod , and formtarget attributes. The only proviso is that you should turn off JavaScript validation. Of course, this means older browsers won't validate your forms before submitting them to the server; but validation still needs to be done on the server to stop spam and other attacks, as well as to eliminate user error. So, any problems will still be caught there. Adopting the HTML5 features will provide a better user experience for visitors using newer browsers without affecting the form's functionality in older ones.

Useful resources:

• The HTML5 inputs and attribute support page detects which form elements and attributes are supported by your browser.
• HTML5 forms specification
• Mark Pilgrim: A Form of Madness (chapter from online version of his book HTML5, Up and Running)
• Ryan Seddon: Forward Thinking Form Validation (A List Apart)