I'm writing a CSS book

JavaScript archives Compatibility CSS coaching Thidrekssaga QuirksBlog Donations Politics Mobile About COH

sitemapcontact

The new input types

On Monday and Tuesday I did some heavy-duty research into the new HTML5 input types and attributes, and I published a desktop and a mobile compatibility table.

Let’s start with some good news. The readonly attribute, which makes a form field read-only, is supported by all browsers, both mobile and desktop. Even IE9. Cool, huh?

The rest of the input story is worse. Much worse. Let’s put it like this: Obigo WebKit, a browser nobody but me has ever heard of, outperforms iPhone and Android.

Initially my plan was to do a quick survey of the desktop browsers, followed by a more in-depth treatment of the mobile ones, not least because a mobile client expects automated tests for the input types. But then it turned out that the new types and attributes aren’t well supported by the desktop browsers, either.

Only two browser vendors have approached this part of the HTML5 spec seriously: Opera and RIM. Both support most of the specification, and also display an understanding of the underlying point of the new input types.

Microsoft, Apple, Google, Samsung, Nokia, and Palm disappoint. As to Mozilla, it is nowhere near Opera and RIM, but what it supports it supports well. And Obigo gets number almost right, which is more than the others can say.

Update: Chrome 10 solves many bugs, and is admitted to the select list of browsers that properly implement the new input types.

Purposes

The purpose of the new types is three-fold:

1. Offering users improved interfaces for certain form-related tasks — for instance a native calendar widget.
2. Restricting user input in certain form fields — for instance allowing only numbers and decimal separators.
3. Validating the form field value and halting form submission if an error is found — just as our old and reliable form validation scripts do.

Note that the last two are mutually exclusive: you only need validation if you don’t restrict user input. But you must have one of the two. That’s the whole point of the new input types.

Not all three purposes are valid for every type. search, for instance, is only about an interface, because it is very hard to restrict input or validate a search query. On the other hand, number is the ideal candidate for user input restriction, while the pattern attribute depends entirely on validation.

Unfortunately most browser vendors don’t understand the input restriction and validation purposes. Only Opera, BlackBerry WebKit, Firefox on desktop, and Safari on Windows validate the field and halt form submission in case of mismatches — provided they support the type. The rest, including Safari on Mac and iOS, doesn’t.

Thus Safari fails on Apple’s own two platforms, but passes on Microsoft’s. Go figure. You can’t make this up. Nobody would believe you.

Dates

The ultimate example of a proper HTML5 form control is dates and times. Validation functions for dates and times, and their writing process, have been a pain point ever since JavaScript was invented. Wouldn’t it be insanely great if the browser handled it for us? And gave the user a nice widget for ease of input?

Opera and RIM have understood these issues, the others haven’t. Both vendors force the user to work through browser widgets — in RIM’s case BlackBerry’s native ones, in Opera’s case a rather ugly (but workable) calendar that unfortunately scales rather badly to mobile. (Hint: give it an absolute position and let it zoom with the page.)

Now the user is given an easy way to insert a valid date, and the validation step is not necessary any more. Result: valid dates, happy users, happy developers.

Contrast this to Safari’s and Chrome’s idiotic controls. If you press the up arrow you’re transferred to the year 0, which does not exist, and the down arrow brings you to the year of Our Lord 275,760 or thereabouts. Not useful.

And if I enter This is not a date the browser calmly sends it on to the server. Somebody was asleep during the development of these absurd features.

Numbers

A similar story can be told for numbers (try the arrows! Is that a 10³⁰⁶ or a 10³⁸ you see?), except that Firefox doesn’t support it, and Opera doesn’t do anything beyond displaying a control. Chrome and Obigo restrict user input to numbers, however. That’s something.

Cosmetic changes

Much has been made of the iPhone’s legendary ability to switch the software keyboard when it encountered an <input type="email"> or url — or even number. Switching keyboards, or replacing some keys with others, serves the user interface purpose. But they’re no substitute for input restriction or validation, which the iPhone doesn’t do.

Unfortunately the cosmetic changes department still has quite a few followers. On my Nexus One both Android WebKit and Firefox switch to the numeric keyboard when they encounter an <input type="number">. This does not count as input restriction, however, since the numeric keyboard contains quite a few characters that are not numbers. And neither browser performs a validation.

Showing a nice customised keyboard is not enough. True input restriction or validation is also required.

Funnily enough, Obigo WebKit, an emerging browser that I’m going to keep my eye on, does do proper input restriction, but forgets to switch to the numeric keyboard. That’s much better than what iPhone and Android do, despite the UX error.

Miscellaneous

Some miscellanous bits that caught my eye:

• The autofocus attribute is badly supported on mobile. This actually makes sense: autofocusing on a field also means bringing up the software keyboard, which could gravely disturb the user experience. It’s no coincidence that both browsers that do support autofocus, BlackBerry and Palm WebKit, run on devices with a hardware keyboard.
• Safari on desktop is very picky when it comes to datalists. Always close your options with a </option>, or Safari won’t show anything beyond the datalist.
• What is a URL? Turns out this question is very hard to answer. When I discovered that I mostly focused on the URL This is not a url, which should be rejected. Most browsers accept it thoughtlessly, though.

Conclusion

All in all the new input types and attributes are not very well supported; especially not by the foremost mobile browsers. A lot will have to change before web developers can use the new types and attributes instead of old-fashioned validation scripts.