I may be remembering it wrong but, less than 2 years ago, there was some issue about Android not firing change events on those for some reason and it was in a version of the browser that a lot of users were going to be using for a long time to come because they're weren't getting OTA updates anymore. It may not be a real concern anymore but it's junk like that just makes these things a pain. Unfortunatley, there's no other good way to get the number pad, which I don't think is a real issue unless individual users will be filling out your forms a lot, like for a data entry application, in which case a custom number pad might be worth considering.

1. type=number only accepts the period as a decimal separator, and there are lots of locales using comma for that purpose. Customers often ask us to support commas, which requires type=text and manual validation.

2. One customer requested the ability to enter decimals in a field, but to keep up/down spinner in steps of whole numbers. You can't do that, the step attribute makes any values other than (min + N * step) invalid. I can see some sense in that, but I think the step attribute should only affect the increments/decrements done by the spinner, not completely reject certain values. (Though you can use step=any to mark all values valid and step by 1.0, which is good enough for common cases.)

There is an awful UI problem on iOS and Android with type=number: they both allow invalid values to be entered, but the value given is just "" blank.

The user thinks they have typed in something valid, but JavaScript (or value from form submit) only gets to see "". E.g. use a thousands separator or paste in a trailing space and you will get an error "input must not be left blank".

There are worse issues with the less common input types.