Back on HTML5, section 4.10.7.1.13 defines a number state for inputs. The traditional input for numbers you see inside of OS is a spinbox, a text box containing a number with a set of up and down arrows beside it which allow you to use your mouse to change the input (iirc some OS even let you use the up and down arrow keys).

So far there are two implementations of the number input, in Opera in and WebKit.

Opera gives you a spinner input and lets you use the arrow keys, and in the iPhone OS WebKit optimises the keyboard by placing the numbers at the default top row (why they don't give you one of those nice fancy slot machine style number inputs they worked so hard on is beyond me).

However IMHO both engines have flopped parts of their implementation.

Opera flopped two parts. First the side flop, normally you expect that inputs like the slider buttons work in such a way that they'll continue onwards when you hold them down. While Opera did manage to make the arrow keys fly through numbers, holding down the arrow buttons does nothing, even if you press your mouse button down on the arrow, and then hold it for an hour, when you release you will only increment a single step.

The other flop is in the way it handles and calculates number inputs with a size= specified.

Now a little bit of background, the html5 spec lists the size= attribute under the "content attributes [which] must not be specified and do not apply to the element" list for number inputs. I recall reading a comment on the html5 mailing list that the reason for excluding size= was because user agents should calculate the size of a number input based on the min/max/step you give it. A little side note of my own here, this reasoning fails for two reasons. A) What happens when your type=number has no min or max but you know how many digits it should fit? B) What happened to backwards compatibility? HTML5 inputs were supposed to be backwards compatible. type=number inputs fall back to type=text inputs when the browser has not implemented number inputs yet. text input size has always been controlled using size= (and css of course) and min/max/step values will have no effect on browsers that haven't implemented number. So if type=number is supposed to fallback to type=text why is it that including a size= attribute so that the text fallback doesn't get insanely long makes your html5 document invalid? Shouldn't size= be listed as "do not apply" rather than "must not be specified, ..."?

Opera fails in two ways, it listens to the size= despite the spec telling it to ignore it, and whether it's specified or not it never bothers to use the min/max/step to give you a sane input size (if you give Opera a min, max, and step that only allows 1 digit numbers and omit the size=, it'll give you an input large enough to fit a 10 digit number). In addition to that it also botches the way it calculates how large a size=# input should be, it applies the calculated width to the entire input, including the size of the up/down buttons instead of using that calculation to determine the size of the actual text input portion of the number input. As a result a size=2 input will only contain enough space for half a number, and a size=1 input won't have enough space to fit a single digit at all. So you are left with two choices in browsers without JS, leave Opera users with a number input they can't see the numbers inside, or use a larger input size to make it fit sacrificing your non-opera users (who the heck needs a input large enough to fit 6 digits to type in number that'll never have more than two digits?).

Minor extra annoyance, Opera also screws up css borders around number inputs, instead of cchanging the browser of the text area, it wraps the entire input in a really ugly looking additional border.

WebKit fails even worse, while it's iPhone OS implementation is alright, in desktop browsers it gives you no UI whatsoever (no spinners and no special handling of the up and down arrows on the keyboard) while at the same time claiming to feature tests that it has type=number implemented. As a result inside desktop versions of Safari and Chrome (as well as the pile of other WebKit based things) websites which help their users by including a chunk of JS to give them a js based spinner input inside browsers that don't implement type=number the users get absolutely no spinner input or ui because the browser doesn't give them a spinner, and the js doesn't give them a spinner because the browser tells it that it is implemented.