HTML5 Forms Are Coming
HTML forms have been, to date, quite simplistic. We've had limited options: the text field, the checkbox, the radio button, the textarea and finally the select drop down. Any complex data like phone numbers, email addresses or dates had to be checked by JavaScript. (And you should always and I mean always do server-side validation of the data.)
The input element works overtime by being rendered completely differently based on the type it's given—be that a text field, password, checkbox, radio button, and others. Considering my readership, this is all terribly old and boring to you now. I understand.
New Types
Under the HTML5 umbrella, however, forms are getting a makeover. The new input types are:
- search
- tel
- url
- datetime, date, month, week, time, and datetime-local
- number
- range
- color
In the example of an email field, validation could be performed by the browser, without JavaScript, to ensure that an email address was correctly entered. Even more powerful, it could allow autocomplete based on your local address book.
New Attributes
There are also plenty of new attributes, many designed to aid in constraining the limits of a field. Here is a small subset of new attributes:
- list — points to a datalist element containing value suggestions
- max and min — constrains valid date/time and number values
- pattern — allows a regular expression as a constraint
- placeholder — displays a text hint for the field
Fallback
If you try to use these new type now, browsers that don't recognize the type will fall back to the text type. Unrecognized attributes will similarly be ignored. That means that you could start using it now and when browsers begin to recognize them, you'll be ready. Client-side validation via JavaScript could be layered on in the meantime.
Where things are unclear is how you can tell whether the browser already supports these features. For example, inspecting the type in Firefox returns "text" but Safari and Chrome return "email".
Browser Support
What's most interesting is that we're starting to see some of these features get implemented into browsers.
Mobile Safari (on the iPhone) was quick out of the gate by adding support for number, email and url. No validation is performed but special keyboards for each input type are presented to aid in entering a value.
Most recently, Chrome 5 beta has support for the placeholder attribute.
<label for="email">Email address</label>
<input id="email" type="email" placeholder="jonathan@example.com">What next?
I have qualms about how browsers will handle the complex input types like date and time and so I appreciate the slow and considered implementations to date. Yes, this isn't very much just yet but it's encouraging.
Conversation
Placeholder has actually been in Chromium/Mac for a few versions.
You can check out what your browser supports over here: http://www.miketaylr.com/code/input-type-attr.html
as well as UI support here:
http://www.miketaylr.com/code/html5-forms-ui-support.html
Is it sad that I dream of the day when placeholder is completely supported? I am serious. I had a dream about it.
@Mike Taylor: I question how accurate those checks are because it indicates that required and pattern attributes are supported but no action is taken on those. And I'm talking Chrome, not Chromium (as I understand it, Chromium is the developer version;correct me if I'm wrong).
Interesting concept of pulling from local address book - not sure I would welcome that addition for an array of reasons. I do like how the iPhone adapts to the type and presents you with the best keyboard layout - that is very useful.
I need to research more and see more of the implementation details - but I will admit I am excited at the thought of being able to use these attributes.
@Snook--
I understand why you'd question that--but feel free to take a closer look at the tests--it's just simple feature detection. I've yet to find an example where these tests are lying. Here's a more concrete example where you can see required and pattern in usage, for example:
http://jsfiddle.net/yebhp/light/
I'd be interested to see if someone *does* find a test that's wrong though, and be happy to update the test page.
Great article Jonathon, opens my eyes to the possibilities. @nefarioustim sent me this today: http://findmebyip.com/litmus#target-selector Looks like Chrome has full support on a Mac, partial support on Windows and you can go whistle for anything else!
@Mike Taylor: Ah, yes, I see what you're saying now. Yes, Chrome allows the values to be specified and the checkValidity method is available (and works), but the work still needs to be performed by JavaScript. This definitely helps. Thanks! :)
That's because they are :)
Trying the tests on this page in Chrome (5.0.356.2 dev - OS X 10.6.2) the inputs with required and pattern function as I expect they should.
Nice write-up Jonathan. The fact that unsupported browsers have a fallback of type="text" is a great reason to start playing around with HTML5 forms now.
While canvas and video will be cool for the bells and whistles, I think these are the elements that are really going to help the everyday web.
Thanks for making sense of the new HTML5 Forms. It will be a while before it all comes into play but good to get a jump on it for us designers and developers.
Thanks Jonathon, there isn't a lot being said about the form attributes for HTML 5 at this time and I find them a great improvement. thanks for the write up.
We've had an experimental implementation in Opera for a couple of years now, that includes type=date (a date picker widget), type=range (a slider), type=email and type=url with validation, datalist (a new input type that allows you to suggest some options like a select box, but which also allows a user to type in their own value). There are such things as type=number min=1 max=11 step=3 and the output element that allows you to feedback to the user the current position of a slider/ the sum of two entered numbers etc. Almost any input type can accept the pattern attribute - you give it a JavaScript-style regex and the browser will validate against that pattern.
It's an "experimental" implementation as we're ironing out the User Interface, but you can try demos I made (using Opera 9+) at
http://people.opera.com/brucel/demo/html5-forms-demo.html
When HTML5 first came out of the gate I was disheartened that XHTML was given up. However, I've gotten over it pretty quickly and am quite excited to start using the new markup that HTML has to offer. This is some pretty cool stuff!
Although implied, by Chrome's support, it's also worth noting Safari 4 also supports basic placeholder text
There's a great article about HTML5 forms over at Dive Into HTML5 (http://diveintohtml5.org/forms.html).
Thank you for ignoring Opera.
Opera has html5 forms implementation since 2007, back then web forms 2.
@Mors: you mean there are people that use Opera? I kid, I kid. Sorry for missing out on Opera. Bruce Lawson has thankfully come to the rescue.
Opera 10.50 has more support for HTML5 then any other browser and you failed to mention it. Makes it feel like a failed article IMO.
@Mike Taylor
Really liked the site you set up for viewing what was supported. Makes it much easier to pick what to start using..
What ever happened to XML Forms? :-(
http://www.w3.org/MarkUp/Forms/
mxt
THINK
think different
Think Open Source
If you use Modernizr for testing for HTML5 support, this
(provide-html5)is a pretty useful jQuery add-on that'll provide fallbacks for the new<input>attributes (likeplaceholderand the like).I use this right now on a few projects, the only drawback being is that the font color isn't changed in say... Firefox. Another way to achieve
placeholderin particular is to usejquery-example. Actually, I'm sure the two can be combined for one über fallback. Just haven't tried that yet.That said, the new field types are a lot of fun. Only ones I haven't gotten around to testing are the ones Opera supports for (unfortunately) obvious reasons.
@Bryan
I've been "cloning" HTML5's placeholder functionality in jQuery for awhile now. This gist is an exact copy-paste from a current project.
A colleague of mine (Eli Van Zoeren) wrote a jQuery plugin that lets you use these new capabilities:
http://www.newmediacampaigns.com/page/nmcformhelper
In browsers that don't support features, they are emulated in javascript.
As Opera originally proposed Web Forms 2, was the first to implement them and still supports them more than any other browser, it would be nice (and fair IMO) if the article could be edited to give Opera even just a brief hat-tip.
As various people noted, we (yes, I work for Opera) have had an experimental implementation of this for years.
We included the repetition model that was around at the time - something that was a cool feature out of Xforms, which basically made it easy to mark a section of a form as a template, and then add more of them (or remove them). I used the feature in Xforms to make simple data-management tools really easily, and it would work really nicely with a native database interface (or for that matter a native RDF interface, if you're that way inclined). Unfortunately we were the only ones who expressed interest in it and it has since been dropped as a proposal for HTML5 ;(
Really nice Jonathan. It's the first time i'm seeing this and i can say i'm astonished by what HTML5 will be capable of. I guess attackers won't be able to enter stupid values to email field by disabling javascript :)
HTML has done nothing but amazing me since the first time i heard about it. I don't know how long will it take for it to become fully usable within all browsers but i hope they will add more capabilites when it becomes a standart so we can minify javascript :)
As nice as this is, with 60+ percent of the internet still using Internet Explorer, we'll likely never see it fully work. Which means hacks (again).
XForms and HTML5 Forms aren't incompatible and many XForms implementations, such as mine ;-), are now based on HTML Forms.
It's good to know that HTML5 Forms will natively support features already in XForms because it will be better for performance.
The less Javascript instructions, the more productivity, speed and reliability. It's true for XForms and HTML5 Forms.
It could also be worth noting that the recent Firefox alphas has support for the "placeholder" attribute too ;-)
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28HTML5%29
Didn't know about the input types for email, search, url. Thanks for the tip!
I'm curious how big of a mess will HTML5 bring. Will there be cross-browser and cross-markup testing ?
I’m impressed it took 30 comments before someone complained about IE. If only we had something like JavaScript to help bridge the gap for older browsers…
Oh there is JScript alright and we love it. It just makes me sad whenever some new technology comes up and i know that even IE9 will somehow manage to screw it up :)
Great stuff coming for any blog/website designer who struggles with HTML forms on a regular basis - who doesn't?
The placeholder attribute is a killer; finally I can get rid off ugly focus/unfocus JS garbage ;-)
Thank you for this awesome post.
I am definitely book marking your site.
Check out our web design company.

Web Design Los Angeles
In Chrome/Chromuim, even though the browser doesn't stop you submitting the form you can use the checkValidity state for user feedback via CSS eg.
input:valid {background-color: green;}
input:invalid {background-color: red;}
Simple example
The behaviour between browsers on how they show that something is invalid is confusing e.g. A field with a pattern attribute in Opera will stop the form from submitting and popup a little helper to indicate that the field is invalid. Whereas Chromium will submit the form as though everything is ok, you do have the invalid pseudo-class do indicate to a user that something is wrong. The only way to stop Chrome submitting the form is to use javascript and the checkValidity() function.
Another concerning approach is the hideous icons Opera have used for their url, email date picker fields which at the moment have no way of turning off or styling.
I fear that the inconsistencies between browsers when it comes to HTML5 form validation will be the new headache that web developers face.
Ryan, the hideous icons in Opera are gone in 10.50 (v soon out of beta in Mac/ Linux).
I know this because I work for Opera, I too thought the icons hideous so campaigned long and hard internally for their removal. And won.
Bruce, that is great news it looks much better now.
Looking over the HTML5 spec it doesn't seem to state any where that form submission will be stopped if a field is invalid, however I did see a form can have a novalidate attribute which stops the form from validating leading me to believe Opera has the behaviour right?
Is the tooltip that shows up when a field is a mismatch a left over from web forms 2.0?
What is your opinion of HTML5 forms vs. xforms?