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.
The purpose of the new types is three-fold:
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.
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.
A similar story can be told for numbers (try the arrows! Is that a 10306 or a 1038 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.
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.
Some miscellanous bits that caught my eye:
autofocusattribute 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.
</option>, or Safari won’t show anything beyond the datalist.
This is not a url, which should be rejected. Most browsers accept it thoughtlessly, though.
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.
I’ll be around at the following conferences: