Forms are how we interact with websites. We use forms to contact site owners, login to applications, reply to comments and so much more. Forms generally don’t inspire love. We don’t like filling them out or creating them. html5 forms want to help change that.
html5 is introducing some enhancements to forms. There are new form elements, new input types, and new attributes to make all our lives a little easier.
There’s a caveat. Currently browser support for many of the new html5 form features isn’t there. Opera is actually leading the way and should support everything mentioned below.
With other browsers support is mixed. However there’s good news. The fallback for much of what I’ll talk about here is an ordinary text input so you can safely use everything now.
I’ve created a demo to show off some of what’s new with html5 forms. Check the demo in the latest version of Opera if you really want to see what these new features look like.
Also there are 3 form images (like the one directly below) that link to tutorials that will look much nicer than my demo.
New Form Elements
In addition to the usual inputs and text areas, html5 forms provide several new elements briefly described below.
- progress — represents task completion. For example with image uploading
- meter — represents a scalar measurement within a range
- keygen — provides control for a key-gen pair. The- private key is stored locally and public key is sent to the server during form submission
- output — displays the results of a calculation
- data list — is like a combination text input and select box
The first two I previously talked about when discussing html5 semantic elements. I mention them again because they make sense to use in combination with forms.
Of these elements meter has the least support, being available only in Opera and Chrome, while output is supported across the board. The one I want to cover in more detail here is datalist.
A datalist appears to be an ordinary text box, but when it has focus a list of options will be shown below. You can choose one of the options or type a new one.
To create a data list you begin with a simple text input and then you add the list attribute and specify the name of your list.
<input type="text" list="list-name">
The value of list then becomes the id of your datalist.
<datalist id="list-name"> <option value="value1"> <option value="value2"> <option value="value3"> </datalist>
As you can see it’s pretty easy to set up and it has the advantage or eliminating all those “if other” options you often find in forms.
The fallback is an ordinary text input.
New Input Types
The input element is what will see the most change with html5 forms. There are a variety of new input types to go along with text, radio, checkbox, etc.
Again browser support isn’t all that good with these new inputs, however in most cases the fallback is a text box. Because of that there really isn’t any harm in using many of these as long as you don’t rely on them.
Search
The new search type will behave like a text box, but will give browsers the ability to style the input to better match the default styling of search boxes.
<input type="search">
Perhaps not significant in terms of functionality, but the styling cues can communicate quite a bit.
Contact
Several of the input types relate to contact information. Again these will behave like an ordinary text box for browsers that don’t support them, but they will in the future allow browsers to react differently based on the expected data.
Each should be self-explanatory and each naturally expects a different formatted response.
In the future a browser might indicate that an email was missing the @ symbol or perhaps add the http:// to a url where it’s missing. They might also require a correct number of digits in a phone number.
<input type="email"> <input type="tel"> <input type="url">
Mobile Safari currently shows different keyboards based on these input types. For example it shows a number keypad for an input asking for a phone number.
Sliders and Spinners
Two new input types expect a range as a value, one being the appropriately named range type and the other being the number type. Both are supported in Opera, Safari, and Chrome.
Again a regular text input is the fallback.
<input type="range"> <input type="number">
Range will present a slider that looks like the left side of the image above. By default it will accept values between 0 and 100, but those can be changed with new min and max attributes, which we’ll cover in a bit.
The range input shows a sliding scale, but it doesn’t show the actual values along that scale. You can easily show the min and max value on either side of the input, but range is more for choosing a relative amount than an exact number.
The number input type creates a spinner (right side of image above) that shows the exact values and lets you increase or decrease those values via the up/down arrows on the side or the up/down arrows on your keyboard.
Color Picker and Date Picker
Usually when we want to add a color or date picker in a form we turn to Javascript. If you’ve ever added one you know it’s not always the easiest or most elegant solution.
<input type="color"> <input type="date">
The color input type aims to add a native browser color picker. It’s only supported in Opera at the moment, but it works as advertised.
Clicking brings up a small palette of colors along with an option that opens the default color picker of your operating system.
Several date related input types are available. Descriptions below are how they currently work in Opera.
- date — brings up a calendar and allows you to choose any date as well as move between different months.
- month — shows the same calendar, but any selection grabs the entire month instead of a single day
- week — similar, but shows which week number (1-52) for the year on the left and any selection in the calendar choose a full week
- time — shows a 24 hour spinner that can be increased or decreased with the up/down arrows
- datetime — combines date and time. On the left is the date picker and to its right the time spinner. It also adds time zone information
- datetime-local — same as datetime, but without the time zone information
Opera supports these fully and Safari and Chrome are showing a time spinner for all the above.
These pickers aren’t very well supported, but again in browsers that don’t yet support them at all they appear as a simple text box.
New Input Attributes
In addition to the new elements and input types we’ll have some new attributes we can use. I’ll detail some below..
Placeholder — allows you to insert placeholder text in an input, which you might use for additional cues as to the type of data expected.
placeholder="insert placeholder text here"
The placeholder text will appear as light gray and typically disappears once you start typing or immediately upon the input gaining focus. It should return if the user leaves the input without having typed anything inside.
While it might be tempting to forgo labels and use placeholder instead, remember that not all browsers support it yet, and the text may disappear as soon the input receives focus.
Autofocus — can be a nice way to get people into a form on loading the page. You use it simply by adding the autofocus keyword inside the input.
<input type="email" autofocus />
You can use autofocus on any form element (text, textarea, select, email, color, etc), but it can only be used once on the page.
It may or may not make sense to use depending on the page. It works for Google since nearly everyone is looking to type something into the lone text box upon loading the search page.
On other pages where the user might want to do something other than start your form it could be annoying to automatically be inside a form input as keys for scrolling won’t work as expected.
Autocomplete — is another attribute you may or may not choose to use depending on your particular form. Autocomplete takes the boolean on and off, with on being the default.
<input type="email" autocomplete="off" />
Most browsers today have autocomplete features, which are generally something we want. However with some information such as credit card numbers or login information we may not want the browser completing all that information.
It’s unlikely you’ll explicitly turn autocomplete on, but where sensitive data is collected setting it to off is probably appropriate.
Required — How many of you would like to never have to add Javascript validation to a form again? I’m raising my hand.
<input type="email" required />
The required attribute will leave validation up to browsers. When trying to submit a form without filling out a required field, both Opera and Firefox reload the page with the first required field at the top with a clear popup letting you know the field is required.
Firefox then shows additional incomplete required fields with a red border, while Opera gives no indication of these additional fields.
All inputs should still be checked on the server side, but this will offer a nice convenience to your visitors.
While not all browsers currently support it, we can take a step toward the day when they will and use the required attribute as described above.
We can then treat required like we would class=”required” in our Javascript validation. Instead of matching the class though, we’ll match the attribute.
Pattern — In the future a browser might require an email input to contain an @ symbol or a tel input to use a specific format of numbers. Until then we can use the pattern attribute to do that without their support (assuming they support the pattern attribute)
<input type="tel" pattern="regular expression" />
The pattern attribute requires a regular expression as its value and the input will reject data that doesn’t conform to the regular expression.
Ideally browsers will implement the more common expected data values, but it’s good to know we can use our own as well.
Readonly — is an attribute that does what you would expect. It removes the ability to edit a form field. You might choose to use it on forms that otherwise allow editing of profile data. Perhaps everything other than the existing username can be changed.
<input type="text" readonly />
Min/Max — I mentioned these above when talking about the range and number input types. They do what you expect.
<input type="number" min="1" max="10" />
The above would set a number spinner with accepted values of 1–10. Values outside the range should not be allowed and won’t be included in the spinner.
Step — is another attribute that will work best with the above min and max attributes. By default we’d move from min to max in integer steps, but you can control the steps by setting the attribute.
<input type="number" min="2" max="10" step="2" />
The above now only allows the selection of even numbers in the range of 2–10
These aren’t the only possible attributes we may see in html5 forms, but I’ll leave the discussion there. You can check this post at HTML5 Rocks for a few more.
Styling HTML5 Forms
You’ve probably been frustrated at one time or another trying to style forms without success. As much as I’d like to tell you otherwise these new elements, input types, and attributes won’t change that.
For now you won’t be able to style your own calendars or color pickers or some of the other things mentioned here. Hopefully in time we’ll have that ability, but there could be some reason for not allowing it.
For example it makes sense for a search input to look like other search inputs in the browser. They may not be styled exactly how we’d like on our pages, but for the user it’s probably more helpful if they look like the other search fields they see to match the schema of the browser.
The same reasoning could be applied to a color picker or date picker.
Javascript Fallback
With some of the above you may only want to use a new attribute if the browser supports it and use the same old Javascript solution you’re currently using. In his book HTML5 for Web Designers, Jeremy Keith offers a simple Javascript function to serve as a generic tester.
Here’s Jeremy’s function.
function elementSupportsAttribute(element,attribute) { var test = document.createElement(element); if (attribute in test) { return true; } else { return false; } } and here’s how you would use it to test for the placeholder attribute.
if (!elementSupportsAttribute('input','placeholder')) { // JavaScript fallback goes here. } Similar is the following function and test for one of the new input types.
function inputSupportsType(test) { var input = document.createElement('input'); input.setAttribute('type',test); if (input.type == 'text') { return false; } else { return true; } } if (!inputSupportsType('range')) { // JavaScript fallback goes here. } 
Summary
I think you’ll agree that many of these new additions to forms will be very useful. I’m particularly excited for the date picker and color picker, which are always something of a pain for me to add.
Unfortunately we need a lot more browser support before we can rely on new elements, input types, and attributes. They work great in Opera and to a limited degree in other browsers not named Internet Explorer.
Fortunately we can still use them as the fallback for most of the new is what we commonly use today. Go ahead and add a placeholder for those browsers that support it. Those that don’t simply won’t see it, much like they don’t see it right now.
Where critical you’ll need to rely on something other than these new html5 form features, but for non-critical information you can safely use them now and begin preparing for the eventual browser support.
