I'm writing a CSS book

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

contact

Retesting the input types

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 required and pattern.

Quiz

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:

* 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.

Purpose

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:

1. The browser could perform a validation and show an error message and refuse to submit the form when an incorrect value is found.
2. The browser could also restrict the accepted input — for instance by not allowing letters in an <input type="number">.
3. Finally, the browser could also give the user a nice interface — for instance the various date pickers in Opera, BlackBerry, and Safari iOS.

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.

Findings

With that said, my findings were the following:

• readonly is still the only universally supported attribute or type.
• IE10’s support is decent, though not great.
• Opera and BlackBerry added support for color.
• Firefox on desktop has added datalists, but its interface is an autosuggest, and not a complete list of options, as IE and Opera show.
• Firefox Mobile, however, has a very nice interface (see screenshot) that I hope other mobile browsers will pick up.
• Firefox Mobile does not show any error messages, though, while Firefox desktop does.
• Chrome dropped support for the date types. That’s curious, because Chrome 10 supported them reasonably well. I can only assume a major re-factoring is going on.
• Safari desktop dropped support for dates, datalist, email, and url. Since they were hideously buggy previously, this makes sense. I assume they’ll reappear.
• Safari on iOS added support for dates, numbers, and ranges. The interface for the range slider is a bit confusing, though.
• Android 3.2, MeeGo and UC support autofocus, but they cleverly don’t pop up the software keyboard, which would be very annoying. As far as I’m concerned this should become a mobile standard.
• Still, poor Android can’t do anything right. Android 3.2 tried to add support for number and range, but the range slider is invisible, while the number type restricts user input only to actual numbers. No negative numbers; no exponents.
• And then BlackBerry, which in my previous round of testing was the best browser. The PlayBook 2 default browser dropped support for required, pattern, email, url, step, and month (though not the other date types). The old BlackBerry Torch (OS6) supported them all fine. I’m not sure what’s going on here, and I hope the PB 2 final version will restore these types.