Name: Age: – Zip Code: Fave Color:

Calendars, colour swatches, sliding widgets, client side validation: this is the nirvana that the HTML5 forms module promises. Some would say “So what? I’ve seen this on the web for years!”, and they’d be right. There have been some really brilliant people coding some really interesting widget and validation frameworks, so why should we change?

Ease the markup learning curve: HTML5 form widgets and validation have been built to be as dead simple to markup as a select box with no JavaScript knowledge required

HTML5 form widgets and validation have been built to be as dead simple to markup as a select box with no JavaScript knowledge required It’s a W3C standard: so you know that it’ll work for years to come and if you have problems, you could always ask almost anyone in the web development community for help.

so you know that it’ll work for years to come and if you have problems, you could always ask almost anyone in the web development community for help. Cellular phone support: HTML5 form fields will have optimized user interfaces appropriate for the type of device. Blackberry already has optimized versions of the date/time and color widgets and, according to Mark Pilgrim’s article A Form of Madness, the virtual keyboards that appear when using HTML5 form fields are optimized for the data being input.

HTML5 form fields will have optimized user interfaces appropriate for the type of device. Blackberry already has optimized versions of the date/time and color widgets and, according to Mark Pilgrim’s article A Form of Madness, the virtual keyboards that appear when using HTML5 form fields are optimized for the data being input. Web development tools will have to support it: It’s a safe bet that Aptana, Dreamweaver, and all the other IDEs out there will have HTML5 support.

It’s a safe bet that Aptana, Dreamweaver, and all the other IDEs out there will have HTML5 support. It’s HTML5: when you tell your non-techie co-workers that you use it, you will be the envy of all — after all, it must be five times better than regular HTML, right? Your boss will be so impressed that you are now a guru in this futuristic technology with a cool numbered acronym that he or she will give you a big fat raise!!! (Okay, okay. Don’t try to laugh too hard … your co-workers will start to worry).

The Support Dilemma

Unfortunately, today’s support for the HTML5 Form Module is spotty with each browser supporting different parts of the specification. Take a look at Wikipedia’s HTML5 Forms comparison chart. You’ll see each browser supporting a different set of features, but not one supports them all.

But I Want To Use It Now!!!

Since I am impatient and want to use HTMl5 Forms right now, I put together the html5Forms.js library. html5Forms uses Modernizr to detect if there is native support for the parts of the HTML5 Forms specification a page wishes to use — if a browser doesn’t support the desired feature, html5Forms uses Modernizr’s yepnope lazy loader to grab some battle-tested third party JavaScript libraries to add support — html5Forms would not be possible without them. We shall discuss these scripts while we discuss the different parts of the HTMl5 Forms specification below.

Form Validation Using the required and pattern Attributes

The required attribute makes an input field mandatory and forces the user to enter in a value in order to submit the form data. The markup is simple

<input type="text" name="firstName" value="" required="required" />

(Note:, you can also just use required on its own if you aren’t trying to be XHTML compliant.)

The pattern attribute forces the user to enter in a value using a specified format. It uses regular expressions to define this format. For example, if you want to force the user to input a U.S. Zip Code inside a form field, you would use the following markup.

<input type="text" name="zipCode" value="" pattern="[0-9]{5}([-][0-9]{4})?" required="required" />

Note that required and pattern are independent from each other. You can have a pattern set on a form field without it being required (i.e. the pattern would only be checked if the user enters in data into the field).

Opera 10+ (mobile and desktop editions) is the only browser that supports the validation routines natively. To use this in all other browsers, all you need is to include the following script tags in the head of your document.

<script type="text/javascript" src="/path/to/shared/js/modernizr.com/Modernizr-2.5.3.forms.js"> </script> <script type="text/javascript" data-webforms2-support="validation" src="/path/to/html5Forms/shared/js/html5Forms.js" > </script>

Note the data-webforms2-support="validation" in the script tag for html5Forms.js. This tells html5Forms to load Weston Ruter’s webforms2.js (which polyfill html5Forms validation. However, it only loads this script if the browser doesn’t support validation natively (The data-webforms2-support attribute can contain other HTML5 Form features in a comma delimited list, but more on that later).

Let’s take a look at how validation looks in the various browsers:

Windows Mac Linux Firefox 4.0+

(native support) Safari 5.x-

(polyfill) Not Applicable Chrome 17+

(native support) Opera 11+

(native support) Opera 10.10 (native support) Similar to Windows version Similar to Windows version IE8

(polyfill) Not Applicable IE10

(native support)

(Note: Although the validation message bubbles look different in every browser, there is a way to apply a common style. Read my follow-up post, Cross Browser Styling of HTML5 Forms — Even In Older Browsers for more information.)

See an example of pattern and required in action.

Note that the same validation framework checks the values of inputs of type email , url and number to ensure that the values are in their respective valid formats. As an added bonus, if you are using the iPhone or iPad version of Safari, the virtual keyboard that appears will be optimized for these type of form fields (e.g. when editing a number field, the keyboard that appears contains only digits and the “+”, “-“, and “.” keys. This is native behaviour for iOS, and I hope other mobile browsers, such the Android’s, follow suit.

The autofocus Attribute

The autofocus attribute allows developers to choose which element has focus when the page is loaded. The Google front page has done this via JavaScript, and now, 12 years later, there is finally an HTML attribute to easily handle this.

<input type="text" name="fullName" value="" required="required" autofocus="autofocus" />

Safari, Chrome and Opera support it natively. Other browsers will support it if you ensure the autofocus is set in the data-webforms2-support attribute for the script tag that loads html5Forms.js

<script type="text/javascript" src="/path/to/shared/js/modernizr.com/Modernizr-2.5.3.forms.js"> </script> <script type="text/javascript" data-webforms2-support="validation,autofocus" src="/path/to/html5Forms/shared/js/html5Forms.js" > </script>

See an example of autofocus in action

The placeholder Attribute

A placeholder is a great visual cue to communicate any special information about a field (e.g. a description

of the data to be input, if the field is required, etc).

Syntax is simple:

<input type="text" name="fullName" value="" required="required" placeholder="Required information" />

Safari, Chrome and Firefox support this attribute natively. Other browsers will support it if you add placeholder to html5Forms’ data-webforms2-support attribute:

<script type="text/javascript" src="/path/to/shared/js/modernizr.com/Modernizr-2.5.3.forms.js"> </script> <script type="text/javascript" data-webforms2-support="validation,placeholder" src="/path/to/html5Forms/shared/js/html5Forms.js" > </script>

See an example of the HTML5 placeholder

tag in action.

The range Input Type and output Tag

Easily my favourite of the HTML5 widgets, range gives developers a sliding control to put inside their forms.

The syntax is simple:

<input type="range" name="rangeEl" value="" min="0" max="150" step="1" />

The min and max attributes contain the minimum and maximum values, and step denotes by what increments the range slider increments by when moved. Note that you can use these attributes with the number input type as well, but instead of having the fancy interface, it will use the validation engine to ensure the value follows what these attributes dictate.

At the time of this writing, Opera and WebKit based browsers (like Safari and Chrome), support it natively, and html5Forms uses the Frequency Decoder Slider Widget to implement it in unsupported browsers. To ensure cross-browser HTML5 range element goodness, add range to html5Forms’ data-webforms2-support attribute:

<script type="text/javascript" src="/path/to/shared/js/modernizr.com/Modernizr-2.5.3.forms.js"> </script> <script type="text/javascript" data-webforms2-support="validation,range" src="/path/to/html5Forms/shared/js/html5Forms.js" > </script>

Take a look at the screenshots below. You will see that the way a range field varies among the browsers that natively support it, and even in some of the browsers that use html5Forms:

Explorer 6.x+

(html5Forms support) Firefox 3.5+

(html5Forms support) Safari 4.0+

(native support) Chrome 3.0+

(native support) Opera 10.0+

(native support) Windows Mac Not Applicable Linux Not Applicable Not Applicable

The output tag can be used to show the value of a field, or the result of an operation performed on a number of fields, using JavaScript expressions. Although the output tag may calculate fomulas referencing any form fields, it is useful especially for the range input type so users can see what value the range element is pointing to:

<output onforminput="this.value = rangeEl.value">-</output> <input type="range" name="rangeEl" value="" min="0" max="150" step="1" />

The contents of the output tag is the default value. Note the this.value syntax – I am not sure why the W3C HTML5 working group decided it was needed (why not just have the formula?), but it is. If there are other types of expressions supported in the final specification, they are not supported by html5Forms at this time. Note that in order to apply CSS to the output tag in IE, it is necessary to use Remy Sharp’s HTML5 Enabling Script.

See an example of the range input being used with the output tag.

See an example of the output tag being used without a range field.

Update (May 12. 2011): Since this article was written, the onforminput event has been deprecated in favor of the oninput . I have updated html5Forms to support oninput , and have written article about its oninput support. I encourage you to see the different between the above to examples and the oninput method of using the output tag with range and without range

The datetime , datetime-local , date and week Input Types

At the time of this writing, Opera is the only desktop browser that supports HTML5 date fields. To support the other browsers, html5Forms uses a slightly modified version of DynArch.com‘s Ex-“Coolest” DHTML Calendar (I decided not to use the coolest one because the Ex-Coolest has a more permissive license and it works really well). Now all browsers can support the datetime , datetime-local , date , month and week input fields, and submit these values in a consistent format.

For browsers that don’t support the date tag, all you need to do is add date to html5Forms’ data-webforms2-support attribute:

<script type="text/javascript" src="/path/to/shared/js/modernizr.com/Modernizr-2.5.3.forms.js"> </script> <script type="text/javascript" data-webforms2-support="date" data-lang="en" src="/path/to/html5Forms/shared/js/html5Forms.js" > </script>

Note the data-lang attribute. This is optional and dictates what language pack is used for the calendar. If data-lang is not included, it will use the browser’s default language as given by the navigator.language JavaScript property. For a list of all the languages supported, take a look at the js files inside the html5Forms/shared/js/jscalendar-1.0/lang directory.

Below is a comparison between Opera’s native date widget vs. the one provided by the DynArch/HTML5Widget combo:

DateTime Widget Month Widget Opera Windows Opera Mac Firefox 3.5+ Windows

(html5Forms support)

It looks like the native calendar for Opera for Mac is a smaller than the Windows version – hopefully this is just on my copy of the browser.

The display formats, and they values that they submit to the server, are pretty much the same

Input type Format displayed on page Format sent to server datetime yyyy-mm-dd HH:MM yyyy-mm-ddTHH:MMZ datetime-local yyyy-mm-dd HH:MM yyyy-mm-ddTHH:MM date yyyy-mm-dd yyyy-mm-dd month yyyy-mm yyyy-mm week yyyy-mmW yyyy-mmW

See the HTML5 date widgets in action.

Note: In this example, The Opera Mobile Windows Emulator incorrectly displays the datetime and datetime-local calendars in the upper left-hand corner of the screen, but not the other ones. Since this is Opera’s own calendar widget, and not html5Forms’, this bug will have to fixed by Opera.

The color Input Type

Opera and the WebKit based Blackberry browser are the only ones that I know of that support the color input type. While we wait to see how the major browser manufacturers decide to implement color , you can use html5Forms’ implementation which uses Jan Odvarko‘s jscolor. The script has been configured to allow only allow lower case hexadecimal rgb values to be entered, and that a blank value not be allowed, as per the W3C spec.

Here are the script tags needed to implement this in all browsers:

<script type="text/javascript" src="/path/to/shared/js/modernizr.com/Modernizr-2.5.3.forms.js"> </script> <script type="text/javascript" data-webforms2-support="color" src="/path/to/html5Forms/shared/js/html5Forms.js" > </script>

Below is a comparison between the Blackberry’s implementation (grabbed from the Blackberry Development Blog), Opera’s and HTML5Widget/jscolor’s.

Blackberry Web Browser Firefox 3.5 with html5Forms.js

Opera (initial click) Opera (after clicking the “Other” button)

See HTML5Widget’s implementation of the

color input type.

Note: Like other HTML syntax, color uses the unfortunate American spelling instead of the Queen’s Proper English (i.e. colour). Ensure you spell it incorrectly in order to make this work. ;-)

How Well Do These Libraries Handle the Official Specification?

I have done some testing on some existing examples that use HTML5 forms to ensure that it works the way developers expect. Here are a few examples that I have taken, with the necessary JavaScript added:

However, the HTML5 Forms specification is large, and unfortunately, the libraries included in the html5Forms package don’t implement everything … yet!!!! Since I am really motivated with what HTML5 forms can do, I am committed to completing support to most, if not all, of the HTML5 Forms specification, and I have updated this package many times in the last two years.

Things that I will be working on in the near future are:

Support for other HTML5 form elements , among other things, datalist , number , keygen , time , meter and progress (If you want to polyfill the progress element, read my blog post Cross Browser HTML5 Progress Bars In Depth.

, among other things, , , , , and (If you want to polyfill the element, read my blog post Cross Browser HTML5 Progress Bars In Depth. Support for CSS styling of HTML5 form widgets as well as the ability to style form fields according to their validation state (e.g. :valid and :invalid psudo-classes). While html5Forms does not support the :valid and :invalid psudo-classes directly, form elements that use the polyfill can be styled to mimic that behavior. Please read my blog post Cross Browser Styling of HTML5 Forms — Even In Older Browsers for more information.

While html5Forms does not support the and psudo-classes directly, form elements that use the polyfill can be styled to mimic that behavior. Please read my blog post Cross Browser Styling of HTML5 Forms — Even In Older Browsers for more information. Default styling for some of the new input types , like tel , email , url . Opera for Mac and Opera Mobile are the only browsers I know of that support this for email and url .

, like , , . Opera for Mac and Opera Mobile are the only browsers I know of that support this for and . Support for customizing the validation look and feel. This is one I would love to do, since I’m sure a lot of developers would want to change how validation errors appear on the screen. Unfortunately, the HTML5 specification doesn’t describe a standard way of doing this. Although there is not a common way of styling native implementations of the validation messages, it is possible to create a good cross-browser skin using the polyfill. Read Cross Browser Styling of HTML5 Forms — Even In Older Browsers for more on this.

Although there is not a common way of styling native implementations of the validation messages, it is possible to create a good cross-browser skin using the polyfill. Read Cross Browser Styling of HTML5 Forms — Even In Older Browsers for more on this. In Internet Explorer 7 and lower, the ability to style input types it doesn’t support natively with CSS code like input[type="range"]

with CSS code like Enabling HTML5 forms validation on the server side to ensure data integrity for browser that don’t support HTML5 forms that have JavaScript disabled.

to ensure data integrity for browser that don’t support HTML5 forms that have JavaScript disabled. Support for internationalization of the error messages used in webforms2 . This is not so important now that html5Forms supports setting custom error messages using the input tag’s data-errormessage attribute. Again, read Cross Browser Styling of HTML5 Forms — Even In Older Browsers to find out more.

Integrating With visibleIf To Make Even Cooler Looking Forms

The webforms2 and html5Widgets libraries are designed to co-exist well with visibleIf to create interactive forms with fields that only validate the ones that visibleIf is displaying.

See an example of HTML5 validation working with the visibleIf JavaScript library

Acknowledgments, Shout-outs and Kudos

Further Reading

The W3C HTML5 Forms Specification Working Draft: The Working Draft is in “Last call for comments” status, so there may be some last minute changes.

The Working Draft is in “Last call for comments” status, so there may be some last minute changes. A Form of Madness: Chapter 10 of Mark Pilgrim’s great reference on HTML5.

Chapter 10 of Mark Pilgrim’s great reference on HTML5. Web Forms 2.0 Working Draft: The WHATWG spec that the W3C spec is based on. It includes the repetition model which didn’t make it into the W3C spec

Download

Both html5Widgets and webforms2 both have permanent homes at github (however, the html5Widgets github page contains a copy of webforms2 in it for your convenience). html5Forms, along with all the helper libraries, are available at the html5Forms github repository. The old html5Widgets repo is deprecated and will be going away in the future. I decided to rename the project to html5Forms since html5Widgets.js was really just the widget library for the whole package. Also, Paul Irish once told me he thought it was may more obvious of a name … it just took me two years to be convinced :-)

Download the latest version of html5Forms.js and all the cool 3rd Party scripts from github.