I have retested the support for the new input types (
<input type="number"> and such) in the desktop and mobile browsers.
All in all support has increased slightly since the last time I tested them, although Safari desktop, Chrome, and BlackBerry have seen some decline. Safari and Chrome have mainly done away with badly or buggily implemented types — it’s clear they’re rewriting significant parts of this module.
As to BlackBerry, its decline was a nasty shock to me. Previously it vied with Opera for Best Implementation, but the PlayBook 2 default browser has dropped support for quite a few types and attributes, such as
To understand how complicated these new features can be, consider the following quiz question:
I add an
<input type="number" step="3"> to the page, and the user enters 11. What should the browser do?
You can try it for yourself at the test page. Don’t forget to submit the form. My Twitter followers gave they following replies:
|The browser rejects the 11||17*||IE, Chrome, Opera|
|The browser automagically rounds it to the closest proper value, 12||13||none|
|The browser shows an error message||9||Opera|
|The browser submits 11 to the server||8||Safari|
|The number 11 should be impossible to enter||3||none|
|The browser accepts the value if the
||2||Safari, sort of|
|Mathematics should be changed so that 11/3 is an integer||1||none|
* This total includes the votes for an error message.
So the desired outcome is unclear. The browsers’ behaviours have been documented on the desktop page.
A quick repeat of the underlying purpose of the input types seems in order. In the end, the idea is to not send incorrect values to the server. Thus we can see three purposes:
The last purpose is a nice extra. If the browser offers an interface but doesn’t support either validation or input restriction, I judge its support Minimal. It misses the actual point, after all.
With that said, my findings were the following:
readonlyis still the only universally supported attribute or type.
Upcoming speaking gigs: