Note: This one gets a little ranty.
One of the earlier things I learned how to use in html5 was form types. This sounds really complicated, but it’s actually really easy (that’s why I get so worked up about this).
When these should be used
When creating a form, at least one of those input’s is an email, phone number or zip code. It is really easy to mark these as email, and phone, and zip it not quite as obvious, but still easy. Why do this? Because if you are on a mobile device, the device will pull up a number pad, or an email keyboard (with @ and .com/.edu).
Here is how easy it is
<input type="email">URL
<input type="url">Telephone
<input type="tel">Zip is a little more complex
<input type="text" pattern="[0-9]*">“I can’t use those! I have to support IE8?”
Sidenote: I personally think it doesn’t greatly deteriorate the user experience if you don’t polyfill, but ideally you want to. I realize this adds complexity to implementing these, but if you are taking the time, it is definitely worth it.
If an input is <input type="blahblah"> or a type that the browser doesn’t understand, the input defaults back to text. If you want them to work flawlessly in other browsers, you can progressively enhance these inputs.
“Date” is the one that I can understand why developers wouldn’t want to use
Date support in browsers is a little dodgy and has some pretty ugly date-pickers. It takes a little more work but is worth loading in jQuery UI’s date-picker for the non-supported browsers. This is one type that can’t really go without a polyfill. Chris Coyier explains this well in the progressive enhancing post.
Why does this drive me bonkers?
When I fill out a form on my phone, I really appreciate the experience of a proper keyboard. And as a developer I know it’s as easy as changing the word “text” to “email” or “tel”.
I’m writing this post to get the change the misconception that html5 forms are difficult. I totally get why this exists. There are lots of html5/css3 techniques out there that are either difficult to implement, or hard to polyfill for older browsers, so we are hesitant to use them. HTML5 forms are not one of these. They are super easy and enhance, at the very least, the mobile experience. Oh, and did I mention you get free form validation in supported browsers?
4 replies on “Using HTML5 form types”
any idea what the action button on a mobile device renders as?
is it always just “Go” for web forms or can you specify that via a similar command?
I don’t think you can make the text anything you want, but…
One input type I neglected to mention in this post was “search.” Turns out if you are focused on an <input type=”search”>, it will show a “search” button instead of “Go.”
http://codepen.io/rtvenge/pen/IoAkt
Looks like that’s as close as we can get.
Some of HTML5 types of form fields have serious issues. For example:
* input of
type="search"is unstyleable in Chrome (prefixed properties like-webkit-appearanceare not future-proof);* input of
type="url"forces user to input protocol (this is an HTML-spec design issue that is even not going to be fixed).In fact, input of
type="email"is one of a few (if not the only) HTML5 form-field types that can be used safely in practice.Hey Marat,
I appreciate the info on some of the quirks with these input types. I did have some thoughts on your findings:
1. I forgot about this limitation as I went back and looked at an older WordPress site I did and, sure enough, I used
-webkit-appearance. I took a look at the W3C spec, and there is no mention of styling limitations. As far as I can see, this issue is only in webkit, so I would guess the Blink engine fork will fix it.2. I think this is the intended result of type=url. I would say that if you want to assume the user wants http://, have javascript add the
http://to the input onFocus if it’s empty. I wouldn’t even consider this a workaround or a hack, but an enhancement to a url input.I would still not discourage developers from using these input types, but just like anything else, you should be testing.