Firefox 4 will come with better support for HTML5 forms. In the latest beta we are experimenting with a set of new features: more inputs types (email, url, tel, search), new attributes (placeholder, autofocus, list), decoupled forms and different validation mechanisms. This is thanks mostly to the hard work of Mounir Lamouri.
Some examples will work in other browsers, but you’ll need Firefox 4 beta to see all of them.
New input field types
In the same fashion as new HTML5 elements, we have new field types to better express what kind of input we want. The look and feel of many of these elements is the same as a text field, but they carry a different semantic meaning. This means that browsers can optimize the experience for users. For example, a mobile browser can provide a specific keyboard for a field. Or the browser can pre-fill phone number fields based on people in your address book. And extensions may even provide some features based on those types.
In this beta, Firefox comes with four new kind of inputs :
Of the four new input types,
We also have support for a new kind of field:
for attribute is a list of IDs of the fields that intervene into the calculation.
Text fields have been improved with
<datalist> support. You can easily provide a list of suggestions for a field as the user is typing. You bind the field and the datalist by using the
list attribute. It will use every
option element inside
datalist to populate the list. And for browsers without
datalist support, they will display the content of the
datalist element. So be sure to provide some valid markup to get a nice fallback.
New input attributes
The value of this attribute will be displayed inside the form when it is empty and not focused. You can put an example of the kind of expected value.
You have more options to define the interaction between fields and forms.
<input> elements don’t need to be children of a <form> element anymore. You can define them anywhere you want and bind them to a form using the new
form attribute. It takes the ID of the form it should bind to.
Here’s an example. Let’s say you’re working on a search engine for some blogging software. You want a very simple form for the general use case and some advanced options if the user needs more control.
At the top of the page you could put:
And at the bottom:
This will behave as if the search field was part of the form. And you get the freedom of placing it wherever you want in your HTML.
Form options on fields
All the options that can be defined at the form level can be overridden at the field element. All submit fields (<button> and input type=”submit”) accept four new attributes : formenctype, formaction, formmethod and formtarget.
One use case could be a form with a preview and post buttons. Each one needs all the fields of the form but they perform a different action.
When the user clicks on the Preview button, its attributes will override the form’s attributes. In this case, instead of a POST request to new_post.php, the whole form will be sent to the preview.php script with a GET method.
By adding this attribute, you’ll mark this field as required. For text fields, it means that it shouldn’t be left empty. For checkbox buttons, it means it should be checked. And for radio buttons, it means one of the button for a group should be selected.
Try each of the examples below and you’ll see that they change color when you interact with them.
URL fields are automatically validated.
Emails are also automatically validated. By passing the multiple attribute (also valid on type=”file”), you can also validate a list of mails separated by commas.
In the example below, try hovering over the text field. You should see a popup that tells you how to fill out the form.
The constraint validation API
If you need even more control over the validation, you can use the
setCustomValidity method. If you provide an empty string to this method, the element will be considered valid. Otherwise, it will be marked as invalid and the string will be used as a tooltip to help your user understand the problem.
If one of the field of a form is not valid, then submitting the form will be blocked and the first invalid field will be focused with a message explaining the problem. If you want to override this behaviour and send the form anyway, you can add a
novalidate attribute on the form or the
formnovalidate attribute on the appropriate submit button.
If you want more details on the validation mechanisms, check out Mounir’s blog post.
New CSS selectors
And to go with all this goodness are a few new CSS selectors.
All fields are marked as
:optional by default. If they have the required attribute, they’ll match the
:required pseudo-class instead.
These pseudo-classes represent the state of the field regarding validation. You can use
:invalid to override the default styling that Firefox 4 provides.
Here’s an example of a text box where the default style has been overridden.
This pseudo-class targets input fields displaying a placeholder. This is not yet part of CSS, so you’ll need to use a pseudo-element for WebKit based browsers.
Form features in HTML5 are very new, and there’s still a wide difference between browsers. Opera implemented part of the spec (it was called Webforms2 at that time) so it has decent support for HTML5 Forms, along with some quirks since the spec evolved since that implementation. WebKit-based browsers are currently implementing some parts of the spec so you’ll also find some early support there as well.
We will not be adding more form features in Firefox 4, and there is clearly still some work to get full support for HTML5 forms. New field types (numbers, colors, dates), new attributes (step, min, max), new events (onforminput, onformchange) and so on. We’ll be adding support for more of HTML5 forms in later releases.
This was just a rough introduction. To get all the details, you should go to the documentation on Mozilla Developer Network.