HTML5 offers a lot of exciting new features in the realm of forms. One of the new additions to forms in HTML5 is the placeholder attribute. Placeholder text is the “hint” or “example” text that resides in a text input field before the user clicks in (or tabs to) that field — and goes away the moment the field is in use.
HTML5 Forms is probably the most practical and will be the most commonly used module of the HTML5 spec. With it, you can create great looking; easy-to-use forms that can validate each field as a user types. Many of the modern browsers (i.e. Firefox 4.x+, Chrome 17+1, Opera 10.x+, IE 10+) support the HTML5 Forms spec natively, and it is possible to add support to the other browsers (Safari1 and IE 9.0-).
New form controls
As forms are the main tool for data input in Web applications, and the data we want to collect has become more complex, it has been necessary to create an input element with more capabilities, to collect this data with more semantics and better definition, and allow for easier, more effective error management and validation.
The first new input type we'll discuss is the number type:
<input type="number" … >
This creates a special kind of input field for number entry – in most supporting browsers this appears as a text entry field with a spinner control, which allows you to increment and decrement its value.
Figure 1: A number input type.
Creating a slider control to allow you to choose between ranges of values used to be a complicated, semantically dubious proposition, but with HTML5 it is easy — you just use the range input type:
<input type="range" … >
Figure 2: A range input type.
Listing1: User interaction with the form
<output onforminput="value=weight.value"></output> <input type="date"> and other date/time controls
HTML5 has a number of different input types for creating complicated date/time pickers, for example the kind of date picker you see featured on pretty much every flight/train booking site out there. These used to be created using unsemantic kludges, so it is great that we now have standardized easy ways to do this. For example:
Listing2: Data Picker
<input type="date" … > <input type="time" … >
Respectively, these create a fully functioning date picker, and a text input containing a separator for hours, minutes and seconds (depending on the step attribute specified) that only allows you to input a time value.
Figure 3: date and time input types.
But it doesn't end here — there are a number of other related input types available:
- datetime: combines the functionality of two we have looked at above, allowing you to choose a date and a time
- month: allows you to choose a month, stored internally as a number between 1-12, although different browsers may provide you with more elaborate choosing mechanisms, like a scrolling list of the month names
- week: allows you to choose a week, stored internally in the format 2010-W37 (week 37 of the year 2010), and chosen using a similar
- datepicker to the ones we have seen already
This input type brings up a color picker. Opera's implementation allows the user to pick from a selection of colors, enter hexadecimal values directly in a text field, or to invoke the OS's native color picker.
Figure 4: a color input, and the native color pickers on Windows and OS X.
The search input type is arguably nothing more than a differently-styled text input. Browsers are meant to style these inputs the same way as any OS-specific search functionality. Beyond this purely aesthetic consideration, though, it's still important to note that marking up search fields explicitly opens up the possibility for browsers, assistive technologies or automated crawlers to do something clever with these inputs in the future – for instance, a browser could conceivably offer the user a choice to automatically create a custom search for a specific site.
Figure 5: A search input as it appears in Opera on OS X.
<datalist> element and list attribute
Up until now we have been used to using <select> and <option> elements to create dropdown lists of options for our users to choose from. But what if we wanted to create a list that allowed users to choose from a list of suggested options, as well as being able to type in their own? That required fiddly scripting – but now you can simply use the list attribute to connect an ordinary input to a list of options, defined inside a <datalist> element.
Listing3: Connecting input to a list of options
<input type="text" list="mydata" … > <datalist id="mydata"> <option label="Mr" value="Mister"> <option label="Mrs" value="Mistress"> <option label="Ms" value="Miss"> </datalist>
Figure 6: Creating an input element with suggestions using datalist.
<input type="tel">, <input type="email"> and <input type="url">
As their names imply, these new input types relate to telephone numbers, email addresses or URLs. Browsers will render these as normal text entry inputs, but explicitly stating what kind of text we're expecting in these fields plays an important role in client-side form validation. Additionally, on certain mobile devices the browser will switch from its regular text entry on-screen keyboard to the more context-relevant variants. Again, it's conceivable that in the future browsers will take further advantage of these explicitly marked-up inputs to offer additional functionality, such as autocompleting email addresses and telephone numbers based on the user's contacts list or address book.
Make use of the above process to get your HTML forms compatible across different browsers. Hope you liked the tutorial. See you next time.