Rethinking Forms in HTML5

While there are many changes for the better in the HTML5 specification, there is no better bang for the buck for the data driven website than the transformation of forms. These simple changes will transform how you enter, validate, process, and even display inputs. You will be able to create more usable web applications with less code and less confusion.

Introduction What’s in Store?

“In the recent past, the majority of innovation in forms have come from the use of JavaScript, rather than old fashioned HTML. While there is nothing wrong with using JavaScript to enhance forms, it does bring its own usability along with many development headaches.”

HTML 5 is still undergoing changes before it is finalized. If you look at the spec, you will see that there is still a last call for comments along with statements, such as, Implementers should be aware that this specification is not stable. Furthermore, particularly for the purposes of this tutorial, focusing on the changes to forms, browser implementation is spotty to say the least. That said, the changes on the horizon are worth examining today. While the changes are major in scope, the implementation for developers look to be rather easy. In this tutorial, we will take a high level overview of these ground breaking changes, and think about how they will impact the nature of user input.

In the past, changes to forms have been relatively minor. If you go back to the HTML 3.2 spec, which was finalized in 1997, you will see the same basic form inputs that you use today. Select, textarea, radio, checkboxes and text were available then. A generation of web developers have grown up writing to these same standards. While later versions of the specification brought changes to forms, such as the fieldset, label, legend, and form actions such as onsubmit or onchange, the way we deal with user input has remained somewhat static. In the recent past, the majority of innovation in forms have come from the use of JavaScript, rather than old fashioned HTML. While there is nothing wrong with using JavaScript to enhance forms, it does bring its own usability along with many development headaches. For instance, there are many different ways that we can validate forms using JavaScript, but what happens when a user does not have JavaScript enabled? We further have to apply logic to our server side scripts. In the end, we have a not so consistent way of handling user input. HTML 5 doesn’t address every innovation headache for forms in the past 13 years, but it does give us plenty of tools to
make our jobs much easier, and allows us to produce much more consistent forms.

There are three basic changes that we should examine. First, we will look at the changes to the input elements, such as autocomplete or autofocus. The second is changes to the input states, and there are quite a few! Finally, we will examine the new form elements. It is important to restate that the specification is in flux; so I wouldn’t be surprised if, in the future, there are subtle changes to what we are discussing. That’s what makes this fun!

Changes to Input Elements: A Whole New Playground.

Input attributes are those items that you place in inputs to explain what the input is doing. For instance:

    <input name="form_text" id="form_text" type="text" value="foo" size="10" maxlength="100">

In the example above, the input attributes are value, size, and maxlength. These have been around for quite some time. HTML 5 doesn’t change the concept of having input elements, but rather adds quite a few more. There does appear to be at least one subtraction, or rather substitution, and that is the change of disabled now appears to become readonly. The spec does not go into detail to the change, but if I was a betting man, the change would allow event handlers, such as onblur, to fire – which a disabled element prevents.

The new attributes include autofocus, autocomplete, list, required, multiple, pattern, min and max, step and placeholder. I think of these as two different flavors of elements. The first flavor enhances the experience for the user, while the second enhances the development experience. What I mean by this, is autofocus, autocomplete, list, multiple, and placeholder helps the user experience in selecting items, or perhaps by giving a description of what the form input is looking for, or by aiding in completing the form. required, min and max, pattern and step add to the development experience by saying what should be in the form itself.

Autofocus

What each of these new attributes do is relatively easy to understand. For instance:

    <input name="form_text" id="form_text" type="text" value="foo" autofocus>

Above, the autofocus element focuses the text input on page load. This means that as soon as the page loads, this text input is ready to take an entry. You can start typing right away, as this element has the focus of the document. Something that we used to do in JavaScript in a line or so, can now be done with a single word.

    <input name="form_text" id="form_text" type="text" value="foo" autocomplete="off">

In the above example, by turning off autocomplete, you keep the browser from filling in the form field from a previous value. Nothing bugs me more than seeing my credit card number come up in a form as soon as I type a digit. The default for autocomplete is to be on, so the only time you need to use this element is when you want to prevent the form field from completing from previous entries. It adds to the user experience by keeping sensitive information from just “popping up.”

List

    <input name="form_url" id="form_url" type="url" list="url_list">
    <datalist id="url_list">
        <option value="http://www.google.com" label="Google">
        <option value="http://www.nettuts.com" label="NetTuts">
    </datalist>

The list attribute is very cool. Essentially, you provide a datalist, and it will create a drop down from your text input. Think of it as a natural auto complete. Take it a bit further, and instead of having to add a JavaScript library for a quick look up, based on key entries, you could easily just add an “onchange” event handler, with an AJAX post, and you end up with a drop down that gets more specific as the user types into the box. With HTML 5, this functionality an be created with just a few lines.

Multiple

<input name="form_url" id="form_url" type="url" list="url_list" multiple>

The multiple attribute allows you to select multiple items from your datalist. For instance, you might have a form which sends messages from your website. By using the multiple element, you can allow the user to select multiple recipients to send that message. Again, this is something we can accomplish with a bit of JavaScript now, but with HTML 5, we only have to add a single command to the form.

Placeholder

    <input name="form_text" id="form_text" type="text" placeholder="Type Here">

The placeholder attribute is something we have been doing for years with a touch of JavaScript. What this does is, as soon as the input is focused, Type Here will vanish. If there was no change to the text on blur, then Type Here will reappear. Once again, we are taking some JavaScript out of the picture to enhance the user experience.

Required

These next new attributes all enhance our development. With the exception of “step,” each aids in the validation of the user input.

    <input name="form_text" id="form_text" type="text" value="foo" required>

The required attribute is exactly as it sounds. I, the developer of this webpage, require you to fill out this form prior to hitting submit. This is the basic form validation that we use today with JavaScript. What took a library before to add a required entry, now takes a single word in the form.

RegEx

    <input name="form_text" id="form_text" type="text" value="foo" pattern="[0-9][A-Z]{3}">

Of all the new form attributes, this is the one that I am most excited about. Mr. Form, let me introduce you to my good friend, Regex. Thats right, we can validate form entries based on regular expressions. While this one is going to be mystifying at first, as you learn regular expression, the possibilities of validation now become limitless.

Validation

    <input name="form_range" id="form_range" type="range" min="1" max="10" step=".5" value="5" >

I have lumped the final three into one example, as they all deal with number validation – or the range of numbers that we can include.

• Min: is the minimal value that an input will take.
• max: is the maximum input value the input will take.

Each of these are dealing with numerical values. Dont confuse them with maxlength, which deals with the number of characters an input will take. The step element is just as it sounds. As you select a numerical value, step it up by .5 or down by .5 — meaning this input type will have the possible values of 1, 1.5, 2, 2.5, and so on.

As of right now, to the best of my knowledge, browser support is somewhat spotty on these attributes. Heres a quick chart showing what I was able to find on the implementations.

Changes to Input Types: A Whole Lot of Love.

There are eight new input types, not counting all the new date and time types, which for our purposes, I am lumping into one. Its important to note that the browsers which have not implemented the new input types will degrade to a type of text on each that I have tested. What the new input types bring is an ability to validate user input based upon the type that you are using. There is also more validation to come which I will be discussing in the next two sections. Each of the new input types allows us to separate from a text field to something more specific. For instance, to take integer or float values prior to HTML 5, we mostly used an input type of text. Just from the annotation, it is counter intuitive for beginners. By being more specific, we then have better visual control over our interface, as the more specific the element in HTML, the greater control you have from within the CSS, and the easier it is to define those visual elements. In addition, with the new specific input types, browsers are now able to fine tune what the input range should be. Finally, with the advent of mobile computing, we are able to make web application form elements which can be styled to look like natural applications, or can shape the keyboard that we are using.

Let’s look at number handling first:

Numbers, Integers and Floats

    <input name="form_range" id="form_range" type="range" min="1" max="10" step=".5" value="5" >

    <input name="form_number" id="form_number" type="number" min="1" max="10" >

Each of these input types allows us to play with numbers, and when we post the forms, we should be sure that we have those float values for our server side processing without the added JavaScript validation. Simply put, for each of these types, we are expecting to get numbers back within the range that we define and with the step that we want. The difference between the two types is how they are displayed. While I am waiting to see implementation on the number type, I would expect either a roll, or a text box, or possibly a type of a select with numbers. The range type is a bit different, in that it looks like a sliding value, similar to what you would expect to see for a volume control.

Dates and Times

    <input name="form_date" id="form_date" type="date">

    <input name="form_month" id="form_month" type="month">

    <input name="form_week" id="form_week" type="week">

    <input name="form_time" id="form_time" type="time">

    <input name="form_datetime_local" id="form_datetime_local" type="datetime-local">

Another big relief to standardize your backend development is the new date and time input types. From the Opera implementation that I have seen, each shows a calendar drop down, which allows your user to select a date. Again, we can validate on our webpage that the input is in the format that we are expecting. Each does exactly what you would think; you are selecting a month, week, day, or time. The one that is a little different is the datetime-local, which is showing the date and time without your timezone offset. For instance, if you are selecting a flight, the datetime-local would show the time and date in the city that you are going, which is not necessarily the timezone that you are currently in.

Urls, Emails, Telephone, and Color

    <input name="form_url" id="form_url" type="url" list="url_list">
    <datalist id="url_list">
        <option value="http://www.google.com" label="Google">
        <option value="http://net.tutsplus.com" label="NetTuts+">
    </datalist>

    <input name="form_email" id="form_email" type="email" list="email_list" multiple>
    <datalist id="url_list">
        <option value="jane.doe@test.com" label="Jane Doe">
        <option value="john.doe@test.com" label="John Doe">
    </datalist>

    <input name="form_telephone" id="form_telephone" type="telephone">

    <input name="form_color" id="form_color" type="color">

Each of these input types are descriptive. The URL and Email types both have the validations of valid url patterns and valid email patterns. The telephone does not, however, conform to any specific pattern. It just strips line breaks. If you want to enforce a validation pattern on the telephone field, you can always use the pattern element. Each of these elements minus color will also take the list attribute, minus color. Color is the oddball of the bunch; I can see its practical use, where you can select a color from a fancy pull down that shows colors, and enforce the text entry of something like #000000, but it doesn’t really fit the rest of the changes, in my opinion. Its like playing which one is not like the others.

Like the attributes, the input type browser implementation is quite spotty. My iPhone seems to support more of these than Safari, which is a bit funny to me. This is the best that I could find, as to support.

Changes to Form Elements: Not Quite as Drastic

The number of changes to the form elements is not as drastic as input attributes and types. That said, there are a few new elements to be aware of. We have already covered datalist – it is how we define what will be selected from a list element call – but we haven’t seen keygen, output, progress, or meter. Outside of keygen. these aren’t quite as self explanatory as the new attributes. Lets dig into these just a bit.

Keygen

    <keygen name="key">

This one is a bit confusing. It does not generate a public key for you. Instead, it is a key pair generator control. Once the form is submitted, it packages the key pair to store the private key in the local key store, and sends the public key back to the server. It will generate the client certificate and offer it back to the user to download. Once downloaded and stored with the private key, you can then authenticate services, such as SSL or certificate authentication.

Output

    <input name="number_1" type="number"> + <input name="number_2" type="number"> =
    <output onforminput="value = number_1.valueAsNumber + number_2.valueAsNumber"></output>

Think of the output element as a text area on steroids. What you can do is calculate from two number type text inputs and output that calculation without ever submitting the form back to the server. If you just return false onsubmit, in the above example, it will calculate number_1 plus number_2, and provide you the answer. Like many things discussed in this tutorial, this is something that we can accomplish today with JavaScript, but this really lessens the amount of code that we need to write in the future.

Progress and Meter

    <progress id="p" max=100>0% </progress>

    <meter min=0 max=20 value=12 optimum=10>12cm </meter>

The final two new elements are progress and meter. They are similar, but with one difference. Progress is meant to be used to measure the progress of a specific task. For instance, if you might have five more pages to complete before a survey is done, you would show the progress element in that area. The meter, on the other hand, is a measurement of something. You might want to show the remaining disk space a user has left. You would use the meter to display that measurement. There are new boundary elements, such as low, high and optimum. These supersede the min or max elements; so if they exceed them, they become the new lower and upper limits of the form.

Like the rest of the HTML 5 form changes, browser implementation is poor at the moment. Heres what seems to work, and what doesn’t (at the time of this writing).

Conclusion

From what I can see, there is no reason to not start using HTML 5 forms. The input elements and types all degrade nicely, even in IE6, where they are either ignored as elements, or degraded to text inputs. We are going to have to wait a while for the validation attributes to become a reality, but with that said, there are still some uses today without those advantages. For instance, the iPhone modifies the keyboard if you are using the url, email, or number types. The range input type is already supported in WebKit browsers, so you could be the first kid on the block with a number slider that works without JavaScript. The spec is rapidly finalizing, and browsers are catching up rather quickly to the paradigm shifts. There is no time like the present to at least begin playing with these new toys! What do you think?