HTML5 introduces several new input types that you can use to better describe the type of data your users are entering. In addition to the standard text fields, radio buttons, and checkbox elements, you can use elements such as email fields, calendars, color pickers, spinboxes, and sliders. Browsers can use these new fields to display better controls to the user without the need for JavaScript. Mobile devices and virtual keyboards for tablets and touchscreens can use the field types to display different keyboard layouts. For example, the iPhone’s Mobile
Safari browser displays alternate keyboard layouts when the user is entering data into the URL and email types, making special characters like (@), (7), (7), and [/) easily accessible.
Improving the AwesomeCo Projects Form
AwesomeCo is working on creating a new project management web application to make it easier for developers and managers to keep up with the progress of the many projects they have going on. Each project has a name, a contact email address, and a staging URL so managers can preview the website as it’s being built. There are also fields for the start date, priority, and estimated number of hours the project should take to complete. Finally, the development manager would like to give each project a color so he can quickly identify each project when he looks at reports.
Let’s mock up a quick project preferences page using the new HTML5 fields.
Setting Up the Basic Form
Let’s create a basic HTML form that does a POST request. Since there’s nothing special about the name field, we’ll use the trusty text field.
<form method=”post” action=”/projects/l”>
<fieldset id=”personal_information”>
<1egend>Proj ect Information</legencb<ol>
<li>
<label for=”name”>Name</label>
<input type=”text” name=”name” autofocus id=”name”>
</li>
<li>
<input type=”submit” value=”Submit”>
</li>
</ol>
</fieldset>
</form>
Notice that we are marking this form up with labels wrapped in an ordered list. Labels are essential when creating accessible forms. The for attribute of the label references the id of its associated form element. This helps screen readers identify fields on a page. The ordered list
provides a good way of listing the fields without resorting to complex table or div structures. This also gives you a way to mark up the order in which you’d like people to fill out the fields.
Creating a Slider Using Range
Sliders are commonly used to let users decrease or increase a numerical value and could be a great way to quickly allow managers to both visualize and modify the priority of the project. You implement a slider with the range type.
<label for=”priority”>Priori ty</label>
<input type= “range” min=”0″ max= “10”
name= “priority” value=”0″ id =”priority”>
Add this to the form, within a new li element just like the previous field. Chrome and Opera both implement a Slider widget, which looks like this:
Priority
Notice that we’ve also set the min and max range for the slider. That will constrain the value of the form field.
Handling Numbers with Spinboxes
We use numbers a lot, and although typing numbers is fairly simple, spinboxes can make making minor adjustments easier. A spinbox is a control with arrows that increment or decrement the value in the box. Let’s use the spinbox for estimated hours. That way, the hours can be easily adjusted.
<label for=”estimated_hours”>Estimated Hours</label>
<input type=”number” name=”estimated_hours”
min=”0″ max=”1000″
i d=”estimated_hours”>
Opera supports the spinbox control, which looks like this:
Estimated Hours
The spinbox also allows typing by default, and like range sliders, we can set minimum and maximum values. However, those minimum and maximum ranges won’t be applied to any value you type into the field. Also notice that you can control the size of the increment step by giving
a value to the step parameter. It defaults to 1 but can be any numerical value.
Dates
Recording the start date of the project is pretty important, and we want to make that as easy as possible. The date input type is a perfect fit here.
<label for=”start_date”>Start date</label>
<input type= “date” name=”start_date” id =”start_date”
value=”2010-12-01″>
At the time of writing, Opera is the only browser that currently supports a full calendar picker.
Here’s an example of its implementation:
The HTML5 specification says that the email input type is designed to hold either a single email address or an email address list, so that’s the perfect candidate for our email field.
<label for=”email”>Emai 1 contact</label>
<input type=”email” name=”email” id=”email”>
Mobile devices get the most benefit from this type of form field, because the virtual keyboard layouts change to make entering email addresses easier.
There’s a field type designed to handle URLs too. This one is especially nice if your visitor uses an iPhone, because it displays a much different keyboard layout, displaying helper buttons for quickly entering web addresses, similar to the keyboard displayed when entering a URL into Mobile Safari’s address bar. Adding the staging URL field is as simple as adding this code:
<label for=”url”»Staging URL</label>
<input type=”url” name=”url” id=”url”>
Virtual keyboards use this field type to display a different layout as well.
Color
Finally, we need to provide a way to enter a color code, and we’ll use the color type for that.
<label for=”project_color”>Project color</label>
<input type=”color” name=”project_color” id=”project_color”>
At the time of writing, no browsers display a color picker control, but that shouldn’t stop you from using this field. You’re using proper markup to describe your content, and that’s going to come in handy in the future, especially when you need to provide fallback support.
Opera supports most of these new controls right now, as you can see in Figure 3.1, but when you open the page in Firefox, Safari, or Google Chrome, you won’t see much of a difference. We’ll need to fix that.
Falling Back
Browsers that don’t understand these new types simply fall back to the text type, so your forms will still be usable. At that point, you can bind one of the jQuery UI or YUI widgets to that field to transform it. As time goes on and more browsers support these controls, you can remove the JavaScript hooks.
Replacing the Color Picker
We can easily identify and replace the color picker using jQuery with CSS3’s attribute selectors. We locate any input field with the type of color and apply a jQuery plug-in called SimpleColor.
if (!hasColorSupportO){
$C’input[type=color]’) .simpleColorO ;
}
Since we used the new form types in our markup, we don’t have to add an additional class name or other markup to identify the color pickers. Attribute selectors and HTML5 go together quite well.
We don’t want to use this color picker plug-in if the browser has native support for it, so we will use some JavaScript to detect whether the browser supports input fields with a type of color.
Une l function hasColorSupport(){
input = document.createElementC”input”) ;
input.setAttributeC”type”, “co7or”) ;
var hasColorType = (input.type !== “text”);
5 // handle Safari/Chrome partial implementation
if(hasColorType){
var testString = “foo”;
i nput.value=testStri ng;
hasColorType = (input.value != testString);
10 }
return(hasColorType);
}
First, we use plain JavaScript to create an element and set its type attribute to color. Then, we retrieve the type attribute to see whether the browser allowed us to set the attribute. If it comes back with a value of color, then we have support for that type. If not, we’ll have to apply our script.
Things get interesting on line 6. Safari 5 and Google Chrome 5 have partially implemented the color type. They support the field, but they don’t actually display a color widget. We still end up with a text field on the page. So, in our detection method, we set the value for our input field and see whether the value sticks around. If it doesn’t, we can assume that the browser has implemented a color picker because the input field isn’t acting like a text box.
The whole bit of code to replace the color picker looks like this:
if (!hasColorSupportO){
$C’input[type=color]’) .simpleColorO ;
}
That solution works, but it’s very brittle. It targets a specific set of browsers and only for the color control. Other controls have their own quirks that you need to learn. Thankfully, there’s an alternative solution.
Modernizr
The Modernizr2 library can detect support for many HTML5 and CSS3 features. It doesn’t add the missing functionality, but it does provide several mechanisms similar to the solution we implemented for detecting form fields that are more bulletproof.
Before you start throwing Modernizr in your projects, be sure you take some time to understand how it works. Whether you wrote the code yourself or not, if you use it in your project, you’re responsible for it. Modernizr wasn’t ready to handle Safari’s partial support of the color field right away. When the next version of Chrome or Firefox comes out, you may have to hack together a solution. Who knows, maybe you’ll beable to contribute that solution back to Modernizr!
You’ll implement fallbacks for controls such as the date picker and the slider in the same manner. Sliders and date pickers are included as components in the jQuery UI library.3 You’ll include the jQuery UI library on the page, detect whether the browser supports the control
natively, and, if it doesn’t, apply the JavaScript version instead.
Eventually you’ll be able to phase out the JavaScript controls and rely completely on the controls in the browser. Because of the complexity involved with detecting these types, Modernizer will be very helpful to you. However, we’ll continue writing our own detection techniques throughout the rest of this book so you can see how they work.
Aside from new form field types, HTML5 introduces a few other attributes for form fields that can help improve usability. Let’s take a look at autofocus next.