The Boolean required attribute tells the browser to only submit the form if the field in question is filled out correctly. Obviously, this means that the field can’t be left empty, but it also means that, depending on other attributes or the field’s type, only certain types of values will be accepted. Later in the chapter, we’ll be covering different ways of letting browsers know what kind of data is expected in a form.

If a required field is empty or invalid, the form will fail to submit, and focus will move to the first invalid form element. Opera, Firefox, and Chrome provide the user with error messages; for example, “Please fill out this field” or “You have to specify a value” if left empty, and “Please enter an email address” or “xyz is not in the format this page requires” when the data type or pattern is wrong.

The required attribute can be set on any input type except button, range, color, and hidden, all of which generally have a default value. As with other Boolean attributes we’ve seen so far, the syntax is either simply required, or required="required" if you’re using XHTML syntax.

Let’s add the required attribute to our sign-up form. We’ll make the name, email address, password, and subscription start date fields required:

<ul>
  <li>
    <label for="register-name">My name is:</label>
    <input type="text" id="register-name" name="name" 
↵required aria-required="true">
  </li>
  <li>
    <label for="email">My email address is:</label>
    <input type="text" id="email" name="email" 
↵required aria-required="true">
  </li>
  <li>
    <label for="url">My website is located at:</label>
    <input type="text" id="url" name="url">
  </li>
  <li> 
    <label for="password">I would like my password to be:</label>
    <p>(at least 6 characters, no spaces)</p>
    <input type="password" id="password" name="password" 
↵required aria-required="true">
  </li>
  <li>
    <label for="rating">On a scale of 1 to 10, my knowledge of 
↵HTML5 is:</label>
    <input type="text" name="rating" type="range">
  </li>
  <li>
    <label for="startdate">Please start my subscription on:
↵</label>
    <input type="text" id="startdate" name="startdate" 
↵required aria-required="true">
  </li>
  <li>
    <label for="quantity">I would like to receive <input 
↵type="text" name="quantity" id="quantity"> copies of <cite> 
↵The HTML5 Herald</cite></label>
  </li>
  <li>
    <label for="upsell">Also sign me up for <cite>The CSS3 
↵Chronicle</cite></label>
    <input type="checkbox" id="upsell" name="upsell">
  </li>
  <li>
    <input type="submit" id="register-submit" value="Send Post 
↵Haste">
  </li>
</ul>

For improved accessibility, whenever the required attribute is included, add the ARIA attribute aria-required="true". Many screen readers lack support for the new HTML5 attributes, but many do have support for WAI-ARIA roles, so there’s a chance that adding this role could let a user know that the field is required—see Appendix B for a brief introduction to WAI-ARIA.

Figure 4.1, Figure 4.2, and Figure 4.3 show the behavior of the required attribute when you attempt to submit the form.

Figure 4.1.  The required field validation message in Firefox 4

Figure 4.2. How it looks in Opera …

Figure 4.3. … and in Google Chrome

input:required {
  background-image: url('../images/required.png'),
}
input:focus:invalid { 
  background-image: url('../images/invalid.png'),
} 
input:focus:valid { 
  background-image: url('../images/valid.png'),
}

:invalid { box-shadow: none; }

input:required,
input[required] {
  background-image: url('../images/required.png'),
}

The placeholder attribute allows a short hint to be displayed inside the form element, space permitting, telling the user what data should be entered in that field. The placeholder text disappears when the field gains focus, and reappears on blur if no data was entered. Developers have provided this functionality with JavaScript for years, but in HTML5 the placeholder attribute allows it to happen natively, with no JavaScript required.

For The HTML5 Herald’s sign-up form, we’ll put a placeholder on the website URL and start date fields:

<li>
  <label for="url">My website is located at:</label>
  <input type="text" id="url" name="url" 
↵placeholder="http://example.com">
</li>
…
<li>
  <label for="startdate">Please start my subscription on:</label>
  <input type="text" id="startdate" name="startdate" required 
↵aria-required="true" placeholder="1911-03-17">
</li>

Because support for the placeholder attribute is still restricted to the latest crop of browsers, you shouldn’t rely on it as the only way to inform users of requirements. If your hint exceeds the size of the field, describe the requirements in the input’s title attribute or in text next to the input element.

Currently, Safari, Chrome, Opera, and Firefox 4 support the placeholder attribute.

<script>
if(!Modernizr.input.placeholder) {

  $("input[placeholder], textarea[placeholder]").each(function() {
    if($(this).val()==""){
      $(this).val($(this).attr("placeholder"));
      $(this).focus(function(){
        if($(this).val()==$(this).attr("placeholder")) {
          $(this).val("");
          $(this).removeClass('placeholder'),
        }
      });
      $(this).blur(function(){
        if($(this).val()==""){
          $(this).val($(this).attr("placeholder"));
          $(this).addClass('placeholder'),
        }
      });
    }
  });

  $('form').submit(function(){
    // first do all the checking for required 
    // element and form validation. 
    // Only remove placeholders before final submission
    var placeheld = $(this).find('[placeholder]'),
    for(var i=0; i<placeheld.length; i++){
      if($(placeheld[i]).val() == 
↵$(placeheld[i]).attr('placeholder')) {
        // if not required, set value to empty before submitting
        $(placeheld[i]).attr('value',''),
      }
    } 
  });
}
</script>

The pattern attribute enables you to provide a regular expression that the user’s input must match in order to be considered valid. For any input where the user can enter free-form text, you can limit what syntax is acceptable with the pattern attribute.

The regular expression language used in patterns is the same Perl-based regular expression syntax as JavaScript, except that the pattern attribute must match the entire value, not just a subset. When including a pattern, you should always indicate to users what is the expected (and required) pattern. Since browsers currently show the value of the title attribute on hover like a tooltip, include pattern instructions that are more detailed than placeholder text, and which form a coherent statement.

For a simple example, let’s add a pattern attribute to the password field in our form. We want to enforce the requirement that the password be at least six characters long, with no spaces:

<li>
  <label for="password">I would like my password to be:</label>
  <p>(at least 6 characters, no spaces)</p>
  <input type="password" id="password" name="password" required 
↵pattern="S{6,}">
</li>

S refers to “any nonwhitespace character,” and {6,} means “at least six times.” If you wanted to stipulate the maximum amount of characters, the syntax would be, for example, S{6,10} for between six and ten characters.

As with the required attribute, the pattern attribute will prevent the form being submitted if the pattern isn’t matched, and will provide an error message.

If your pattern is not a valid regular expression, it will be ignored for the purposes of validation. Note also that similar to the placeholder and required attributes, you can use the value of this attribute to provide the basis for your JavaScript validation code for nonsupporting browsers.

The Boolean disabled attribute has been around longer than HTML5, but it has been expanded on, to a degree. It can be used with any form control except the new output element—and unlike previous versions of HTML, HTML5 allows you to set the disabled attribute on a fieldset and have it apply to all the form elements contained in that fieldset.

Generally, form elements with the disabled attribute have the content grayed out in the browser—the text is lighter than the color of values in enabled form controls. Browsers will prohibit the user from focusing on a form control that has the disabled attribute set. This attribute is often used to disable the submit button until all fields are correctly filled out, for example.

You can employ the :disabled pseudo-class in your CSS to style disabled form controls.

Form controls with the disabled attribute aren’t submitted along with the form; so their values will be inaccessible to your form processing code on the server side. If you want a value that users are unable to edit, but can still see and submit, use the readonly attribute.

The readonly attribute is similar to the disabled attribute: it makes it impossible for the user to edit the form field. Unlike disabled, however, the field can receive focus, and its value is submitted with the form.

In a comments form, we may want to include the URL of the current page or the title of the article that is being commented on, letting the user know that we are collecting this data without allowing them to change it:

<label for="about">Article Title</label>
<input type="text" name="about" id="about" readonly>

The multiple attribute, if present, indicates that multiple values can be entered in a form control. While it has been available in previous versions of HTML, it only applied to the select element. In HTML5, it can be added to email and file input types as well. If present, the user can select more than one file, or include several comma-separated email addresses.

At the time of writing, multiple file input is only supported in Chrome, Opera, and Firefox.

Not to be confused with the form element, the form attribute in HTML5 allows you to associate form elements with forms in which they’re not nested. This means you can now associate a fieldset or form control with any other form in the document. The form attribute takes as its value the id of the form element with which the fieldset or control should be associated.

If the attribute is omitted, the control will only be submitted with the form in which it’s nested.

The autocomplete attribute specifies whether the form, or a form control, should have autocomplete functionality. For most form fields, this will be a drop-down that appears when the user begins typing. For password fields, it’s the ability to save the password in the browser. Support for this attribute has been present in browsers for years, though it was never in the specification until HTML5.

By default, autocomplete is on. You may have noticed this the last time you filled out a form. In order to disable it, use autocomplete="off". This is a good idea for sensitive information, such as a credit card number, or information that will never need to be reused, like a CAPTCHA.

Autocompletion is also controlled by the browser. The user will have to turn on the autocomplete functionality in their browser for it to work at all; however, setting the autocomplete attribute to off overrides this preference.

Datalists are currently only supported in Firefox and Opera, but they are very cool. They fulfill a common requirement: a text field with a set of predefined autocomplete options. Unlike the select element, the user can enter whatever data they like, but they’ll be presented with a set of suggested options in a drop-down as they type.

The datalist element, much like select, is a list of options, with each one placed in an option element. You then associate the datalist with an input using the list attribute on the input. The list attribute takes as its value the id attribute of the datalist you want to associate with the input. One datalist can be associated with several input fields.

Here’s what this would look like in practice:

<label for="favcolor">Favorite Color</label>
<input type="text" list="colors" id="favcolor" name="favcolor">

<datalist id="colors">
  <option value="Blue">
  <option value="Green">
  <option value="Pink">
  <option value="Purple">
</datalist>

In supporting browsers, this will display a simple text field that drops down a list of suggested answers when focused. Figure 4.4 shows what this looks like.

Figure 4.4. The datalist element in action in Firefox

The Boolean autofocus attribute specifies that a form control should be focused as soon as the page loads. Only one form element can have autofocus in a given page.

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:

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. You can see this behavior in Chrome on Mac OS X in Figure 4.5.

Figure 4.5.  The search input type is styled to resemble the operating system’s search fields

Currently, only Chrome and Safari provide a button to clear the field. Opera 11 displays a rounded corner box without a control to clear the field, but switches to display a normal text field if any styling, such as a background color, is applied.

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. The HTML5 Herald has no search field, but here’s an example of how you’d use it:

<form id="search" method="get">
  <input type="search" id="s" name="s">
  <input type="submit" value="Search">
</form>

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.

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.

Let’s change our form to use type="email" for the registrant’s email address:

<label for="email">My email address is</label>
<input type="email"  id="email" name="email">

If you change the input type from text to email, as we’ve done here, 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), as shown in Figure 4.6.

Figure 4.6.  The email input type provides a specialized keyboard on iOS devices

Firefox, Chrome, and Opera also provide error messaging for email inputs: if you try to submit a form with content unrecognizable as one or more email addresses, the browser will tell you what is wrong. The default error messages are shown in Figure 4.7.

Figure 4.7.  Error messages for incorrectly formatted email addresses on Firefox 4 (left) and Opera 11 (right)

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.

Let’s update our registration form to use the url input type:

<label for="url">My website is located at:</label>
<input type="url" id="url" name="url">

Opera, Firefox, and WebKit support the url input type, reporting the input as invalid if the URL is incorrectly formatted. Only the general format of a URL is validated, so, for example, q://example.xyz will be considered valid, even though q:// isn’t a real protocol and .xyz isn’t a real top-level domain. As such, if you want the value entered to conform to a more specific format, provide information in your label (or in a placeholder) to let your users know, and use the pattern attribute to ensure that it’s correct—we’ll cover pattern in detail later in this chapter.

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.

You can encourage a particular format by including a placeholder with the correct syntax, or a comment after the input with an example. Additionally, you can stipulate a format by using the pattern attribute or the setCustomValidity method to provide for client-side validation.

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.

Let’s change our quantity field to use the number input type:

<label for="quantity">I would like to receive <input type="number" 
↵name="quantity" id="quantity"> copies of <cite>The HTML5 Herald
↵</cite></label>

Figure 4.8 shows what this looks like in Opera.

Figure 4.8. The number input seen in Opera

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.

You can also provide a step attribute, which determines the increment by which the number steps up or down when clicking the up and down arrows. The min, max, and step attributes are supported in Opera and WebKit.

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.

Let’s change our registration form to use the range input type. The field asking users to rate their knowledge of HTML5 on a scale of 1 to 10 is perfect:

<label for="rating">On a scale of 1 to 10, my knowledge of HTML5 
↵is:</label>
<input type="range" min="1" max="10" name="rating" type="range">

The step attribute defaults to 1, so it’s not required. Figure 4.9 shows what this input type looks like in Safari.

Figure 4.9.  The range input type in Chrome

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.

We don’t use color in our form, but, if we did, it would look a little like this:

<label for="clr">Color: </label>
<input id="clr" name="clr" type="text" placeholder="#FFFFFF"
↵pattern="#(?:[0-9A-Fa-f]{6}|[0-9A-Fa-f]{3})" required>

The resulting color picker is shown in Figure 4.10. Clicking the Other… button brings up a full color wheel, allowing the user to select any hexadecimal color value.

Figure 4.10.  Opera’s color picker control for the color input type

WebKit browsers support the color input type as well, and can indicate whether the color is valid, but don’t provide a color picker … yet.

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.

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.

Let’s change our subscription start date field to use the date input type:

<label for="startdate">Please start my subscription on:</label>
<input type="date" min="1904-03-17" max="1904-05-17" 
↵id="startdate" name="startdate" required aria-required="true" 
↵placeholder="1911-03-17">

Now, we’ll have a calendar control when we view our form in Opera, as shown in Figure 4.11. Unfortunately, it’s unable to be styled with CSS at present.

Figure 4.11.  Opera’s date picker for date, datetime, datetime-local, week, and month input types

For the month and week types, Opera displays the same date picker, but only allows the user to select full months or weeks. In those cases, individual days are unable to be selected; instead, clicking on a day selects the whole month or week.

Currently, WebKit provides some support for the date input type, providing a user interface similar to the number type, with up and down arrows. Safari behaves a little oddly when it comes to this control; the default value is the very first day of the Gregorian calendar: 1582-10-15. The default in Chrome is 0001-01-01, and the maximum is 275760-09-13. Opera functions more predictably, with the default value being the current date. Because of these oddities, we highly recommend including a minimum and maximum when using any of the date-based input types (all those listed above, except time). As with number, this is done with the min and max attributes.

The placeholder attribute we added to our start date field earlier is made redundant in Opera by the date picker interface, but it makes sense to leave it in place to guide users of other browsers.

Eventually, when all browsers support the UI of all the new input types, the placeholder attribute will only be relevant on text, search, URL, telephone, email, and password types. Until then, placeholders are a good way to hint to your users what kind of data is expected in those fields—remember that they’ll just look like regular text fields in nonsupporting browsers.

<?php
function daysFromNow($days){
  $added = ($days * 24 * 3600) + time();
  echo(date("Y-m-d", $added));
}
?>

<li>
  <label for="startdate">Please start my subscription on:
↵</label>
  <input type="date" min="<?php daysFromNow(1); ?>" 
↵max="<?php daysFromNow(60); ?>" id="startdate" 
↵name="startdate" required aria-required="true"
↵placeholder="1911-03-17">
</li>

You can also include the step attribute with the date and time input types. For example, step="6" on month will limit the user to selecting either January or July. On time and datetime inputs, the step attribute must be expressed in seconds, so step="900" on the time input type will cause the input to step in increments of 15 minutes.

The purpose of the output element is to accept and display the result of a calculation. The output element should be used when the user can see the value, but not directly manipulate it, and when the value can be derived from other values entered in the form. An example use might be the total cost calculated after shipping and taxes in a shopping cart.

The output element’s value is contained between the opening and closing tags. Generally, it will make sense to use JavaScript in the browser to update this value. The output element has a for attribute, which is used to reference the ids of form fields whose values went into the calculation of the output element’s value.

It’s worth noting that the output element’s name and value are submitted along with the form.

The keygen element is a control for generating a public-private keypair and for submitting the public key from that key pair. Opera, WebKit, and Firefox all support this element, rendering it as a drop-down menu with options for the length of the generated keys; all provide different options, though.

The keygen element introduces two new attributes: the challenge attribute specifies a string that is submitted along with the public key, and the keytype attribute specifies the type of key generated. At the time of writing, the only supported keytype value is rsa, a common algorithm used in public-key cryptography.

Throughout this chapter, we’ve been talking about attributes that apply to various form field elements; however, there are also some new attributes specific to the form element itself.

First, as we’ve seen, HTML5 provides a number of ways to natively validate form fields; certain input types such as email and url, for example, as well as the required and pattern attributes. You may, however, want to use these input types and attributes for styling or semantic reasons without preventing the form being submitted. The new Boolean novalidate attribute allows a form to be submitted without native validation of its fields.

Next, forms no longer need to have the action attribute defined. If omitted, the form will behave as though the action were set to the current page.

Lastly, the autocomplete attribute we introduced earlier can also be added directly to the form element; in this case, it will apply to all fields in that form unless those fields override it with their own autocomplete attribute.

In HTML5, you can have an optgroup as a child of another optgroup, which is useful for multilevel select menus.

In HTML 4, we were required to specify a textarea element’s size by specifying values for the rows and cols attributes. In HTML5, these attributes are no longer required; you should use CSS to define a textarea’s width and height.

New in HTML5 is the wrap attribute. This attribute applies to the textarea element, and can have the values soft (the default) or hard. With soft, the text is submitted without line breaks other than those actually entered by the user, whereas hard will submit any line breaks introduced by the browser due to the size of the field. If you set the wrap to hard, you need to specify a cols attribute.