Rick Strahl's Weblog  

Wind, waves, code and everything in between...
.NET • C# • Markdown • WPF • All Things Web
Contact   •   Articles   •   Products   •   Support   •   Advertise
Sponsored by:
Markdown Monster - The Markdown Editor for Windows

HTML 5 Input Types - How useful is this really going to be?

On this page:

HTML5 introduces a number of new input types that are meant to provide a richer user input experience. It seems like this should be a good thing, given that we've basically been stuck with a very small and limited set of stock input controls in HTML.

HTML5 aims to change that with input type extensions that allow you to edit and validate special types of text input. The new input types that are available in HTML5 are the following:

  • email
  • url
  • number
  • range
  • Date pickers (date, month, week, time, datetime, datetime-local)
  • search
  • color

Some of these act as validators (email, url, number) while others are meant as helpers to provide richer functionality like DataPicker, Range, Color and Search options.

What do you get?

A number of newer browsers now support some of the new HTML 5 input types and provide limited user hints and validation on the client. For example in FireFox 8 if I type in an invalid email address into my login dialog and tab off I get this display:


<input type="email" style="width:250px;" id="Username" name="Username">

and when I submit the form I get:


Chrome does something similar although frankly it looks a lot nicer than the klunky FireFox message.


Note that in both cases the form won't submit until a valid email address has been entered.

Rich Interfaces? Maybe not

In theory browsers are supposed to implement rich interfaces to handle some of these interface types. For example, dates should be shown as a date picker. Current implementations in this department however are really sad at best. Check out the date field displays here in Chrome:


The 'user interface' consists of little more than an up-down button which increases decreases the date by a day. Additionally the date is displayed in universal format rather than locale adjusted format for the current browser or language. AFAIK there's no real clean way to style any of this either.

Opera on the other hand provides a number of editors, but boy are they ugly:


The date picker that actually pops up also isn't any better looking. Even here the date and time are displayed in universal format. Again there appears to be no way to style this stuff so it's bound to clash hard with any UI layout you have.

You can play around with some of these at:



You also need to remember that when you start styling the new HTML5 input controls that you need to include each one of them individually for each style:

.containercontent input[type=text],
.containercontent input[type=email],
.containercontent input[type=search],
.containercontent input[type=url]
    width: 400px;

This is both advantageous and tedious. Advantageous because it provides for semantic styling as you can reference exactly what each input element should look like. But it's also more tedious in that you now have to specify each of 15 or so input types that apply to what used to be text input. It was a whole lot easier to style just input[type=text]. This is not a big deal but just something to think of that will potentially require some extra work for the design layout process.

Good News Bad News

This existing browser behavior of HTML 5 input tags raises all sorts of questions. I already mentioned the styling is a big issue - how do you get the UI to match your HTML's existing layout. But more importantly it seems that the new HTML input element behaviors are going to conflict with existing validation and custom input control types. If you're already using a different date picker like say jQuery UI date picker using code like this:

$().ready(function () {
            .datepicker({ showOn: 'button',
                buttonImageOnly: true,
                buttonImage: '../../images/calendar.png',
                buttonText: 'Select date',
                showButtonPanel: true                        

You can end up with lovely stuff like this:


Ouch! The date box doesn't support my local American date and I can't even submit the form. Major FAIL there.

There are other similar scenarios - the url type attribute in Firefox will complain about an protocol-less url, while in Chrome it'll automatically append the http:// in front of the URL. Either of these behaviors can be problematic depending on what you're trying to achieve in your form.

To be fair you can turn off the form validation on the form submission level:

<input type="submit" id="btnSubmit" name="btnSubmit" value="Save" 
class="submitbutton" formnovalidate="formnovalidate" />

to avoid frivolous validation. But then you might as well use a input type=text control.

So in the end use of the new HTML5 input elements may not be as useful as I had hoped. Lack of control over the input becomes a big problem and lack of styling makes these controls look out of place. Worst of all though the validation can seriously get in the way unless you disable the validation diminishing the value significantly. It certainly isn't going to replace existing client side validation schemes - since you most likely need more sophisticated validation than just these general types. And if you leave it on for the base validations and use custom validations for your custom logic, the two are likely to look very different for a very disjointed feature.

To HTML5 or not to HTML5

There's a big momentum behind HTML5 these days, but every time I look at part of the new features I'm just aghast with how poorly these specs are drafted and don't account for common usage scenarios. Or are too vague to let browser vendors skimp on feature sets that make the functionality work across browsers more consistently (video formats anyone?)

I definitely think that it's high time HTML gets better input support, but the current HTML 5 state of affairs isn't going to help much. In fact, I think it's going to get in the way more than it actually helps…

It seems to me it wouldn't be rocket science to build basic user input controls like a date picker that actually address the 90%+ scenario. Pick a date from a dropdown and display the date in local browser time format. How hard could that possibly be? Or have a URL validator that understands both full URLs and partial URLs. I mean that's a problem that's been solved many times over in just about any application that accepts URLs as user input, right? Heck mobile device browsers actually get this right.

But no, on desktop browsers we get everything in a standards compliant geek format that you can't possibly push on to users. :-( Let's hope going forward that things will improve and more thought to the end user scenarios  will go into the actual browser implementations.

I understand it's not an easy problem to solve - no one solution is going to fit every situation, but the crap that's currently shipping in desktop browsers is next to useless or worse disruptive and actually makes the controls unusable in many scenarios. At the very least these controls need full opt-out settings that leave the styling and validation to the designer/developer, but leaves the semantic markup in place. One can hope…

Your Turn

What do you think? Have you played with HTML 5 input controls? Do you think these new input control features would help you? What would you need to make them useful?

Posted in HTML  ASP.NET  HTML5  

The Voices of Reason


Bertrand Le Roy
December 10, 2011

# re: HTML 5 Input Types - How useful is this really going to be?

For me it's more about semantic markup than really any kind of help the browser gives (which is actually counter-productive as you discovered: "it seems like you are trying to enter a date let me help you..." Noooooo!)
I was actually satisfied with having the new types but the browser doing nothing about it. What I do like is to be able to target them in jQuery and CSS with a input[type=email] selector.

Rick Strahl
December 11, 2011

# re: HTML 5 Input Types - How useful is this really going to be?

@Bertrand - yup my thinking as well. I don't think we're ever going to be able to get the proper behavior out of these input types unless they are more completely exposed components that you can configure - which of course is completely unlikely.

At least validation can be turned off, but I don't think the UI stuff can and right now it totally does the wrong thing - so much so that the date type is completely unusable (non-locale specific date format).

More broken expectations.

Steven Berkovitz
December 11, 2011

# re: HTML 5 Input Types - How useful is this really going to be?

This is one area where jQuery Mobile does a good job of taking these new input types and turning them into something useful. Ranges automatically become sliders, for example.

December 11, 2011

# re: HTML 5 Input Types - How useful is this really going to be?

Just to present a contrary view - in some circumstances (although not all) the browser can present a better UI to the user than the website can. I'm thinking particularly of mobile browsers - the iphone browser at least does take notice of the HTML5 input types and brings up a different on-screen keyboard depending on the input type (although it doesn't recognise *all* the HTML5 input types; still, much better than nothing). Especially on devices with limited screen space, I'd prefer an input GUI optimised for the device I'm on, something the device can usually do better than the website designer.

...which doesn't make the desktop browsers' behaviour any better: ignoring the user's locale preferences is absolutely the opposite of what they should be able to do. It does put you in the unfortunate position that the desktop browsers' UI is so rubbish you want to disable it (whether by just not using the input types at all; or, if we get an official way to bypass it, doing that), but that would probably also kill the (useful) mobile browsers' UI.

Rik Hemsley
December 11, 2011

# Validation is hard

Perhaps the implementor thought it was safer to disallow dates in DDxMMxYYYY or MMxDDxYYYY format, simply because they couldn't be sure which the user was entering (unless one number was greater than 12) so erred on the side of caution? If so, they should have at least provided a hint at how dates _could_ be entered.

It would perhaps be possible to guess what the user's preferred date format might be, by using Accept-Language, but just because someone likes to read one language (including regional variation) doesn't mean they also prefer the 'standard' date format in that region. I know this is a corner case, but is it better to refuse and be safe than accept, guess and be wrong?

As for email validation: It makes sense to allow configuring a default domain in an 'intranet', app, then accepting addresses like 'rickstrahl' as local (append the default domain when talking to a mail server) so I don't particularly like that the validation disallows only local-part (as defined by the RFCs), though I suppose it's easier to follow the RFC BNF strictly. Whether that actually happens is yet to be discovered.

December 11, 2011

# re: HTML 5 Input Types - How useful is this really going to be?

I believe mobile devices change the keyboard slightly for the various input types. Thats actually kinda nice.

Rick Strahl
December 11, 2011

# re: HTML 5 Input Types - How useful is this really going to be?

It's funny that several of you mention mobile input - which is what actually triggered me to take a closer look at this for one of my own apps. Specifically email and url input I wanted so that the keyboard on mobile browsers will show the .com and for URLs show previously accessed URLs.

It's ironic that mobile browsers actually do something useful with this where desktop browsers for the most part get this completely wrong.

I think what's needed for desktop development at least is the ability to use these tags but remove any sort of chrome/behavior for each control individually so we get semantic behavior only on option. You can disable validation (individually or in batch although currently this only seems to work at the form level) but I don't see a similar option for the chrome UI behaviors which is just as important.

Let's hope that browser vendors will at least recognize that displaying dates in locale specific format is a base requirement in order for us to actually use these controls. Even better would be input masks that describe the layout, but that's totally unlikely to get into the spec...

Ah yes, the trials of W3C consortium snails pace decision making process :-) Overly pragmatic and less practicality.

December 12, 2011

# re: HTML 5 Input Types - How useful is this really going to be?

There's also the shadow dom, but it looks a bit messy still: http://glazkov.com/2011/01/14/what-the-heck-is-shadow-dom/

December 12, 2011

# re: HTML 5 Input Types - How useful is this really going to be?

Sadly, I knew I wasn't going to be using the new validation tools the moment I first saw them. There is no way in hell all the browser vendors are going to simultaneously implement proper, consistent support. Furthermore, even if they all did for their next version, we've still got many, many years before IE will support this. IE9 does not perform this built-in validation, so we are going to have to have regular JavaScript to validate input for that browser anyway.

I don't care how good these new tools are (and they aren't really even that good), I'm not writing two layers of client validation (built in HTML 5 validation for good browsers, and regular JS for IE).

December 12, 2011

# re: HTML 5 Input Types - How useful is this really going to be?

Funny that this article was open for me to save to read

In the time between I opened this blog post and had time to read it, I was on a site to purchase something...

The credit card field has the numeric up/down control and I was like "huh? why is that there and what purpose does it server"..... going back and seeing it was 'type=number' answered the part about how the steppers got there, but it seriously makes no sense to have that type there for a credit card field...

I think HTML5 stuff like this is going to be improperly used by a lot of people

Rick Strahl
December 12, 2011

# re: HTML 5 Input Types - How useful is this really going to be?

@Graham - Yup. One thing I think would be nice if there was a generic validation scheme built in for all controls (ie. some way to force validation error messages). In that case a smart library could use the browser validation display mechanism or fall back to its own implementation when that's not available in older browsers.

Either way that's not an improvement.

Like Bertrand said earlier. I really like the fact that we can isolate the semantic markup so we can easily target certain types of controls as dates, but with default implementations that get in the way - this will be very difficult to work with. Currently I don't see how I could possibly use the type="date" fields. I can however see using the "email" and "url" fields.

Browser vendors really need to get their shit together on this. At the very least providing something reasonably useful that's actually usable in a front end (like a date picker drop down and dates display in locale friendly formats with an input mask to allow changing) would be a good start. It seems like mobile browser above all things are getting this right first which is pathetic :-)

Mika Kukkonen
December 12, 2011

# re: HTML 5 Input Types - How useful is this really going to be?

I have used the simplest new input type attributes, like the placeholder and the autofocus, but not the rest. For real input, you need more configuration.

I remember having trouble with jQuery placeholders that mysteriously show up as textbox values in some browsers. HTLM5 placeholder with a jquery.placeholder fallback has worked perfectly so far.

December 13, 2011

# re: HTML 5 Input Types - How useful is this really going to be?

Mobile aside, this is most assuredly a case of where the spec is way ahead of the browser implementation. And like you said styling, for example, each browser manufacturer's calendar implementation could be a css nightmare full of vendor specific selectors. Makes me think we've begun to come full circle eh? "Now how do you write those alpha transparencly selectors for IE again?......"

December 14, 2011

# re: HTML 5 Input Types - How useful is this really going to be?

Specifications are nice, but of course implementation, in this case browser implementation, will lag. Methinks that bringing consumer and community pressure to bear might be the only answer.

If the complaints come from consumers/public at large, rather than just developers complaining about having CSS for each browser that runs their site, you'd get more traction.

Perhaps start some sort of campaign where one plays on the mind programming of the masses: "True Non-HTML 5 compliance is not PC", "Go Green, Use Browser xyz"...

Yordan Georgiev
December 15, 2011

# re: HTML 5 Input Types - How useful is this really going to be?

HTML5-compatible mobile phones will reach sales of 1 billion in 2013, up from just 336 million this year, says research firm Strategy Analytics.
=> HTML5 will be the de-fact UI building language for the next decade.

source: http://news.cnet.com/8301-1023_3-57339156-93/html5-enabled-phones-to-hit-1-billion-in-sales-in-2013/

I guess all the major browser vendors ( also on mobile ) will again start competing by introducing new features, which will be introduced into the standard, thus eliminating all those initial quirks ...

Rick Strahl
December 15, 2011

# re: HTML 5 Input Types - How useful is this really going to be?

@Yordan - one can only hope.

But given the thickheaded current implementations one has to wonder whether browser vendors actually care about users at all.

West Wind  © Rick Strahl, West Wind Technologies, 2005 - 2024