3 ms·

I only use type=text inputs and implement custom logic on top of it; the others are crap, implemented in a rush and very inconsistently across browsers.

mike-cardwell 10y ago
What about type="number" ? There are clear benefits to using it when a user is entering a number and I'm not aware of any drawbacks? One of the benefits is the way some software keyboards display a number based keyboard instead of a qwerty one...
- jasonkostempski 10y ago
  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.
- DCoder 10y ago
  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.)
- robocat 10y ago
  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.
- deleted 10y ago
  [deleted]
sildur 10y ago
You just have defined the whole HTML5 mess. But who needs the W3C, right?
Illniyar 10y ago
Then you are purposely limiting your user's ux in mobile, different keyboards are very helpful. Of course it's a valid choice, but many people will consider this a serious issue.

mike-cardwell 10y ago

What about type="number" ? There are clear benefits to using it when a user is entering a number and I'm not aware of any drawbacks? One of the benefits is the way some software keyboards display a number based keyboard instead of a qwerty one...

jasonkostempski 10y ago
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.
DCoder 10y ago
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.)
robocat 10y ago
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.
deleted 10y ago
[deleted]

sildur 10y ago

You just have defined the whole HTML5 mess. But who needs the W3C, right?

Illniyar 10y ago

Then you are purposely limiting your user's ux in mobile, different keyboards are very helpful. Of course it's a valid choice, but many people will consider this a serious issue.