A Guide to the New HTML5 Form Input Types

Jun 7 2013 by Yigit Kocak | 28 Comments

A Guide to the New HTML5 Form Input Types

There’s a plethora of new HTML5 form input types (13 new ones to be exact) that make creating engaging and easy-to-use web forms much easier for web designers. The new HTML5 input types give us data validation, date picker controls, color picker controls, inline help text, and more in the web browsers that support them.

Advantage of HTML5 Form Input Types

The benefits of these new input types are tremendous for web designers.

First, the new input types reduce our reliance on client-side- and server-side-scripting for validating common data types like dates, email addresses, and URLs.

For mobile UI developers: You know that creating cross-platform web forms using HTML4 standards is a pain. Using HTML5 form input types could make things easier.

For instance, a form written with HTML5 can utilize the mobile device’s native specialized keyboards depending on what the target input type is.

Here’s an example of using HTML4 input types (on the left) for entering dates in a web form versus using the HTML5 date input type (on the right):

The difference between using HTML4 versus the HTML5 date input type.

Notice how the iPhone’s native keyboard automatically switches over to its native date picker control because it knows that the target input is a date.

Here are other examples.

url Input Type

email Input Type

The New HTML5 Form Input Types

Here’s a table of all the new HTML5 input types for your reference.

Input Type Description HTML Markup
date A control for entering the date. <input type="date">
datetime Date and time using UTC date and time format <input type="datetime">
datetime-local Date and time according to your local time <input type="datetime-local">
month Month and year <input type="month">
time The time of day <input type="time">
week Allows you to pick the week and year. <input type="week">
color Allows you to enter a simple color value (which is in hexadecimal color notation) <input type="color"">
email Validates the input using the standard email format <input type="email">
tel Gives you the ability to validate telephone numbers format against a pattern <input type="tel">
search Searches a data set (like a <datalist> HTML element) <input type="search">
range A slider control for picking a number in between two numbers <input type="range">
number Accepts numbers only <input type="number">
url Accepts URLs only <input type="url">

HTML5 Form Input Types Demo

Here’s a live demo of each input type so that you can play around with them.

Note: This demo page will only work on browsers that support these input types, so it might not work properly when you view it.

We also recommend viewing this demo page on different browsers so you can see how each browser treats these input types; they differ drastically in some cases.

Let’s talk about the new input types.

date

date

The calendar date picker is a standard UI design pattern for allowing users to enter date information in web forms. This is useful for asking users to enter their date of birth or credit card expiration date.

This UI pattern is so common that in HTML5, there’s now the date input type that makes it dead-simple to include date pickers in your web forms. No more JavaScript or server-side programming or installing jQuery plugins, you just need HTML markup (and CSS to make it look prettier).

datetime

datetime

This input type is designed to take in a global date and time string.

datetime-local

datetime-local

This input type is for a local date and time string.

month

month

If you want to allow users to enter a month, this is the input type to use.

week

week

If you want to allow users to enter a week (such as the 31st week of 2013) this is the input type to use.

time

time

This is for inputting the time in the the day. Some browsers will use military time by default (e.g. 16:00), while others use the AM/PM format (e.g. 4:00PM).

color

color

The color picker UI design pattern is a way of allowing users to choose a color. The color input type gives you a form input control for a picking hexadecimal color value.

Some browsers (like Safari) won’t show you a color picker UI though, they’ll just check whether or not the data is a hexadecimal color code (e.g. #000000).

email

email

In HTML5-compatible browsers, this input type is set to validate the entered data for the correct email address syntax.

tel

tel

This input type is ideal for taking in phone numbers.

search

search

The search input type is meant to be used with a data set such as the datalist HTML element or the results of querying a MySQL database. It searches the data set for a match, and also gives you a list of suggestions as you type (which is called the autocomplete user interface pattern).

range

range

This input type is another way to get number-related data from users. By default, it has a slider user interface.

number

number

This input type restricts data entries only to numerical values. If you include min and max attributes, it also validates the data input to make sure the number is between the min/max values.

url

url

Theis input type validates the entered data to make sure that it follows the standard URL format.

Conclusion

These additional input types in HTML5 help us build user-centered web forms easier. The modern web designer no longer needs to break his/her back in order to enable more complex data input patterns.

The times are changing for all of us. Let’s not forget to update our forms to match.

Related Content

About the Author

Yigit Kocak is an online web form specialist at JotForm, a service dedicated to help people create, manage, and share online forms.

28 Comments

Mattias

June 7th, 2013

What happens when a non-HTML5 compatible browser renders an input field with a HTML specific type, like type=”email”?

Will it fall back to the default type which is text?

byroot

June 7th, 2013

@Mattias: exacly.

But the real issue is more browser with partial / broken support of these new types.

Napolux

June 7th, 2013

@Mattias
It will fall back to text.

eblin

June 7th, 2013

@Mattias, Yes it will fallback to text.

Jude

June 7th, 2013

@Mattias, Yes. It reverts back to a text field.

Simon Fredsted

June 7th, 2013

Yep, it falls back to a standard textfield. Good idea to add some JavaScript to make sure the formatting is OK in case the fields aren’t supported.
Also, ironically the fields on this page aren’t using the new HTML5 input types :-)

Yigit

June 7th, 2013

That’s correct.

If the browser doesn’t support it, it will behave as regular text fields.

Prateek

June 7th, 2013

Yes it will :)

Paul Irish

June 7th, 2013

@Mattias, Yup, that’s exactly what happens. :) works great.

Leif

June 7th, 2013

“First, the new input types reduce our reliance on client-side- and server-side-scripting for validating common data types like dates, email addresses, and URLs.”

Please don’t say that. Whatever you do on the client, malicious users can still send hand-crafted HTTP requests to your server. Make sure to handle bad input gracefully. Never trust the client to use your client-side validation. It can only augment server-side validation.

Basti

June 7th, 2013

@Mattias
Yes it will fall back to input type text

Daniel

June 7th, 2013

According to W3Schools it will act as a standard text field if it is a non-HTML5 compatible browser.

ghosttie

June 7th, 2013

I look forward to using this in about fifteen years when all browsers support it

sunny

June 7th, 2013

Yes, it will work as text input type for older browsers.

Gina

June 7th, 2013

Yeah, Firefox displays plain old text boxes – making it impossible to figure out the proper formatting to submit.

TheSisb

June 7th, 2013

@Mattias, yes it does.

Rishi

June 7th, 2013

What I liked about the HTML5 inputs is that it follows the stock way of implementing the boxes, like if you use an iPhone, it will show up the same UI for dropdowns, inputs, dates etc and same with Android.

peter

June 8th, 2013

Unfortunately browsers like IE will not be able to handle it.

Jacob Gube

June 8th, 2013

@Leif: You wouldn’t just use client-side validation on critical data that you’re going to be writing into your database.

It’s simply for reducing the load and need of having to validate simple user errors, like a typo in email address format (e.g., typing jacobsixrevisions.com and accidentally forgetting the @). You validate for these simple errors before they need to take a trip to the server or your client-side script. After the data is in the correct format, that’s when you send it to the server for validation, sanitation, and writing into the database.

Imagine this scenario: I enter the wrong email format such as jacobsixrevisions.com. That obviously wrong data gets sent to the server, the server processes that data and tells me, “Hey, your email address is wrong”.

Now imagine this alternative: Let the browser deal with those simple errors.

When the data passes browser validation (or the user exploits/works around our browser-based validation), that’s when you send it to the server (or script) to re-validate and sanitize.

That last scenario is better for me, the user (because I don’t have to wait for the server to respond to tell me that I made a simple typing error) and it’s good for the site owner because it reduces the burden on her servers from validating honest typos, which contributes (in a relatively small degree) to the overall improvement of web performance on her website.

How about using JavaScript for these simple typos? That’s the current solution. But wouldn’t it be awesome if I didn’t have to though? Wouldn’t it be cool If I can just tell the browser through my markup, “Hey this input field is an email address, please treat it as such. You’re very smart, I think you can handle that pretty simple task for most of the people that use you. Thanks, now I can focus on the more complex stuff.”

Jacob Gube

June 8th, 2013

Just a quick question to you all: Should that statement that @Leif quoted be revised for (even more) clarity?

This statement is what I’m referring to: “First, the new input types reduce our reliance on client-side- and server-side-scripting for validating common data types like dates, email addresses, and URLs”.)

I don’t think it suggests to eliminate server-side validation/sanitation. But does that statement give off that message?

Personally, I take it as saying that it reduces the reliance on validating user inputs for common typing errors before even sending it to the server.

Because common knowledge to me would be to validate/sanitize ALL user data going into the server that has the potential of being harmful, because I can’t guarantee that all users will be using browsers that will have these HTML5 validation features, and I also know that browsers, even if they do support these input types, treat them differently, and also because I know that I can manipulate my browser to not validate my inputs if I really wanted to.

Your thoughts appreciated!

Leif

June 8th, 2013

As I suppose my comment suggests I really did read the paragraph as if you were suggesting to do less validation on the server. It obviously *can* be understood to mean that by at least some. In my opinion, that’s reason enough to reword it.

Leif

June 8th, 2013

(You cannot rely on common knowledge when posting things on the Internet — I’m especially concerned about younger developers just getting started; imagine your blog post is part of the “common knowledge” they are currently forming for the rest of their careers.)

arnold

June 8th, 2013

@Leif
yep I do agree with you

it can reduce client-side scripting , because of the new types and new attributes which wasnt mention in the article,

Here is an info about the attributes:
http://html5doctor.com/html5-forms-introduction-and-new-attributes/

If your website will support other browsers who isnt ready for html5 , there are pollyfill for that so it could fallback for a javascript support ,

Here is an info
http://css-tricks.com/progressively-enhancing-html5-forms/

About the server scripting , I would say yes it will still be needed, thats a rule folks.
Never trust users

Yetsi

June 8th, 2013

I tried this with Microsoft Internet explorer 7 and it didn’t work properly. What I am doing wrong?

Jacob Gube

June 9th, 2013

@Leif: Yes, that’s my concern too, that’s why I asked. If there’s even 1 person that could interpret that statement to say that “yay, these input types mean I don’t need to use server-side scripting to validate user inputs anymore,” that means it should be updated. I’ll update it to reduce ambiguity.

Mathew Porter

June 13th, 2013

Some of the input types are going to be amazing for systems and forms, just a shame support isnt entirely there yet to use on projects, although this is the case with most of html5 and css3 markup. In addition to your post here is a nice article listing support for input elements: http://www.wufoo.com/html5/

Šime Vidas

June 14th, 2013

Damn. Support sucks in Firefox :-(

EZ Design Team

June 16th, 2013

Those that are saying that they can not get the forms to show on specific browsers, check out http://html5test.com/. You can get a score for your browser with plug-ins and operating system.

I have tested and posted but did find that Google Chrome on Windows 8 was the best out of the 5 browsers I have installed on my computer. I have 5 because of the designs I already do and like to test cross browsers. Here are my results with no plug-ins:

Safari 5.1.7 on Windows 8 scores 278+2 bonus points out of 500
Chrome 27 on Windows 8 scores 463+13 bonus points out of 500
Internet Explorer 10 on Windows 8 scores 320+6 bonus points out of 500
Firefox 21 on Windows 8 scores 399+14 bonus points out of 500
Opera 12.15 on Windows 8 scores 404+9 bonus points out of 500

Finding from http://html5test.com/

Leave a Comment

Subscribe to the comments on this article.