Site icon Treehouse Blog

Fun with HTML5 Forms

Do you remember your first form? The first time you realised you could send emails through your site, thanks to a hosted service like Bravenet (remember them?!).

Or perhaps you hacked together a cgi script or even some PHP. But when that first email arrived with the subject line ‘test’ you realised that your website had now become interactive. You could now not only interact with your users, but also tailor your site based on their input.

Long Live Forms

Years later forms are still the primary way our users can interact with us, more than just clicking on links or triggering JavaScript events. Indeed, it’s likely the first thing you do when you start up your favourite browser is type a search query into a form.

Forms and form elements, as they appeared in the HTML4 spec, were utilitarian but hardly elegant. So we got smart. We enlisted our ever loyal friend JavaScript to lift forms to new heights, create new types of interaction, and give the user instant feedback and support.

Feature Rich Forms

With a combination of server-side scripting and AJAX we now have feature-rich forms, but all at the expense of programming complexity. Funny thing is, we’re now so used to this sort of code that what is about to happen almost seems too simple.

Inevitably, as is the case with much of the HTML5 spec, HTML has now caught up with the needs of web designers and developers by providing a remarkably simple way of creating usable and even extensible forms.

Email Sign-up Form Demo

I’ve created a demo of an email sign-up form you can check out at


Each form field uses something from the HTML5 spec and we’ll run through it one step at a time. When I refer to a browser supporting a particular feature, I mean the very latest stable release of that browser which you can download from the relevant vendor website.

Of course, when dealing with anything HTML5 related there is a huge browser caveat – some browsers support all some or none of what we’re about to discuss. And it’s changing really fast.

Your best bet at the moment is to use Opera, Chrome or mobile Safari, although we’ll look at browser support a little later on (together with a piece of JavaScript which helps test for certain features).

A Place for Everything

Feature: Placeholder text
Browsers: Chrome, Safari, Firefox 4

I think most of us have played with JavaScript enough to have placeholder text appear and disappear in a form field. You know, it’s normally light grey text which hints at what should be typed in the form field, and once the form field is selected it disappears. Then, when the cursor leaves the form field a check is made, if the field is still empty then redisplay the placeholder text. Such an intuitive thing sounds convoluted when typed out like that, and it needs a few lines of JavaScript to make it happen. But not any more.


Let’s start with the first name. Here’s the code:

Wow! Seriously, go ahead and test it. Isn’t it beautiful?! Simple yes, but also elegant and highly usable. It does exactly what we need it to do, and doesn’t need to get any more complicated than that.

But hold on a second, there’s no sign of type=”text”. Well in the good old world of HTML5 inputs default to text unless otherwise specified; likewise forms methods default to GET unless specified.

No Jacket Required

Feature: Required form fields
Browsers: Opera, Firefox 4

We have all relied on Javascript to validate a form at some point or another. It’s no substitute for good server-side validation (particularly when it comes to security) but it is an excellent way of providing the user instant feedback on their input. One of the many things we validate is that a user has entered data for a required field and this is now something we can do with HTML5!

Here’s what it looks like:

One of the currently under-supported features of HTML5 forms, adding the required keyword allows browsers to validate the form on the client-side much like Javascript can. And until the feature is universally adopted you can future-proof your document by using Javascript to check for the ‘required’ attribute rather than a particular class or name.

Here’s how Opera renders an error on a required field:

When used with type=”email”, the required field can even validate an email address:

You might also notice that the validation is also affecting the border colour. Required elements start off red, and when you type something into them it changes to green. As you move onto the next field it then changes to grey – the default colour.

The same is true of email validation – the email field won’t turn green until you’ve entered a valid email address. This is a nice touch, and it’s added with some simple CSS pseudo-selectors:

input { border: 2px solid #999; }
input:focus { border: 2px solid #6C6; }
input:invalid { border: 2px solid #F00; }

Getting More Specific

Feature: Email, Web & Phone fields
Browsers: Safari for iPhones

First let’s take a look at the code:

All this is doing is telling the browser what type of data to expect which, at this point, is not really of any benefit unless you’re using mobile Safari, probably on your iPhone. Because what Safari can do is change the keyboard layout depending on the type of data that is being inputted.

For example, in an email field it handily offers the @ symbol in the touch screen keypad. If you change the type from email to ‘phone’ or ‘website’, mobile Safari changes the keyboard further. With more and more of us accessing the web through mobile devices this type of behaviour is only going to become more prevalent.

It’s a Date!

Feature: Date Picker
: Opera

This is another example of where custom built widgets may eventually be replaced by browser controls. A date selector is such a useful piece of kit and it’s great to see browser vendors slowly adopt this.

At the moment there is very little control over the date picker but I’m sure that will change of the coming months and years. Imagine, a browser based date picker that you can style with CSS. Perfect!

Here’s the code:

And here’s what it looks like in Opera 10.62:


Now some have commented that this Opera date-picker is far from attractive, but it does serve it’s purpose and it’s a HUGE step in the right direction. There are even some variations on a theme. The above code generates a standard date picker (day, month, year) but we can be more specific:

Datalist – A list of Data

Feature: Datalist
Browsers: Opera

Whilst not quite an auto-suggest feature, datalists allow us to present the user with a range of options to use in a text input box. This is best used when there aren’t too many options, because with no filter applied to the list as you type it doesn’t get any shorter the more characters you input.

Whilst I don’t think you could list every country in the world (as the list would fall off the bottom of the page) you might want to include a few of the more popular ones like so:


(Forgive me if your country is not on that list – it doesn’t mean it isn’t ‘popular’!)

Whilst perhaps not a replacement for a good JavaScript based auto-suggest tool, it is still a useful enhancement to a normal text field. And like most of the HTML5 form elements, it’s easy to implement and greatly adds to user experience.


NB. When testing this code I found that including a Datalist input broke the page in Safari (5.0.2, Mac); it simply stopped rendering the page when it reached the list. It doesn’t seem to have this effect in any other browser.

Forms by Numbers

Feature: Numbers
Browsers: Opera, Chrome, iPhone

The final feature we’re going to take a look at are numbers. By simply specifying an input type as ‘number’ you have access to ‘Increase’ and ‘Decrease’ buttons which allow the user to input whole integers. You will probably see these input types referred to as ‘spinners’ or a ‘spinbox’.


On the iPhone the touch keyboard changes to one that is number-friendly.

As ever the code is easy and very readable:

The min, max, step and value attributes are optional.

Again, I believe using this sort of control needs some thought as no-one  will want to click the button eighty-four times just to enter the number 84, they’ll simply type it in. However for smaller numbers and for altering numbers it’s a useful addition to the web designers arsenal.

But wait, There’s More!

In this article I’ve included what I think are the most interesting and practical additions to HTML forms, but there are others in the HTML5 spec which you might want to check out. They include:

Go ahead and check them out – you might find one of them useful.

Falling Back

The great thing about many of these HTML5 form enhancements is that they will degrade gracefully to standard input boxes. However some don’t play nice at all, even with so-called ‘modern’ browsers.

The date picker, for example, can behave in odd and unusual ways. In Opera it works just fine but in Chrome there is simply an option to increase and decrease a date by one day – starting in 1582!


This is far from helpful and I’d argue a complete #usabilityfail. So how can we serve Opera the date picker and Chrome something else? Our old friend JavaScript, that’s how.

Before we go on to look at the code it’s also worth remembering that not everyone has JavaScript installed. Unfortunately for those users the form may malfunction or even stop the rest of the page loading (see Datalists, above).

Only you can decide how far you want to push the envelope in these fledgling days for HTML5 forms. For personal projects I urge you to heed the words of Salt ‘N’ Peppa, and “push it, p-p-push it real good”.

JavaScript to the Rescue!

With JavaScript we can check to see if a browser supports a particular attribute like type=”number”, and take action based on the result.

I first saw this code suggested by Jeremy Keith in his excellent book ‘HTML5 For Web Designers’ (which I encourage you all to buy):

function checkAttribute(element, attribute) {
 var test = document.createElement(element);
 if (attribute in test) {
   return true;
  } else {
   return false;

You can then check to see if a browser supports a particular feature with something like:

if (!checkAttribute('input', 'placeholder')) {
// No support for placeholders, so add them with JS

A Word on Modernizr

Another way to check if a browser supports a particular element is by using the funky Modernizr script. This handy utility, when included in a page, adds a bunch of classes to the <body> tag that indicates which features are available. A wave of the JavaScript magic wand and you can decide exactly what can and can’t be used on the page.

A typical Modernizr script might look like this:

if ( {
  // This browser supports date inputs. Hurrah!
} else {
  // Oh dear. Time to include your own
  // JavaScript date solution...


Wrapping it All Up

So there you have it – a run through of some of the more useful and supported additions that HTML5 brings to our forms. I hope you can see the potential in some of them for your site and, as with all shiny new toys, I encourage you to play with them on personal projects but use sparingly on commercial outings. At least for now.

The additions to the HTML5 spec are direct responses to how we use the web in the real world, which is what makes them so effective. I’m not sure we’ll ever turn our backs on JavaScript when it comes to validating and controlling forms but usable, elegant form design is about to get a whole lot easier!

Further Reading

If you’re looking for more “input” that’s “on form” then “submit” yourself to these great articles:

Have you tried out HTML5 forms yet? What do you think? We’d love to know!

This article was written by Richard Shepherd.

Exit mobile version