4 ms·

Well... The spec actually says it's not the "correct" thing to do https://www.w3.org/TR/html5/forms.html#number-state-(type=number) https://www.w3.org/TR/html5

by astura 8y ago

Well... The spec actually says it's not the "correct" thing to do https://www.w3.org/TR/html5/forms.html#number-state-(type=number) https://www.w3.org/TR/html5/forms.html#number-state-(type=nu... >The type=number state is not appropriate for input that happens to only consist of numbers but isn’t strictly speaking a number. For example, it would be inappropriate for credit card numbers or US postal codes. A simple way of determining whether to use type=number is to consider whether it would make sense for the input control to have a spinbox interface (e.g., with "up" and "down" arrows). Getting a credit card number wrong by 1 in the last digit isn’t a minor mistake, it’s as wrong as getting every digit incorrect. So it would not make sense for the user to select a credit card number using "up" and "down" buttons. When a spinbox interface is not appropriate, type=text is probably the right choice (possibly with a pattern attribute).

deleted 8y ago
[deleted]
benatkin 8y ago
Right, so yes, number shouldn't be used to invoke the numeric keypad. Got it. I agree with another commenter that it would be better if it were called magnitude. Still, even when it's the correct thing to do I still think it's a bad feature because it can be accidentally triggered. There's a gotcha in Safari when using pattern for zipcodes or anything that can have a leading 0: https://www.filamentgroup.com/lab/type-number.html#support-leading-zeros https://www.filamentgroup.com/lab/type-number.html#support-l...
crazygringo 8y ago
So... how are you supposed to trigger a numeric keypad on mobile then, for things that aren't technically a number but are composed entirely of digits? Serious question. Edit: kibibu below says it's the "inputmode" attribute, but it only works in Chrome currently. :( https://html.spec.whatwg.org/multipage/interaction.html#input-modalities%3A-the-inputmode-attribute https://html.spec.whatwg.org/multipage/interaction.html#inpu...
- function_seven 8y ago
  I use type=“tel” for that. Works better than “number”.
  - CivilianZero 8y ago
    Was looking for this to be in the comments somewhere. Thumbs up.
thaumasiotes 8y ago
As far as I can tell, a spinbox interface is not appropriate in any circumstance, even when your semantics are unambiguously numeric. This is mentioned in the article too: "Dammit! I wanted to buy two pairs of socks, not 39." A spinbox only makes sense if you don't care what the value is, such that any two nearby values are exactly equivalent. And that is what the W3 guidance you quote says: > Getting a credit card number wrong by 1 in the last digit isn’t a minor mistake, it’s as wrong as getting every digit incorrect. [And that's why a card number field should not use a spinbox.] This suggests to me that the real problem is the idea that "type=numeric" means you want a spinbox. You don't ever want a spinbox; there's no reason for any attribute to give you one. But you frequently do want to restrict the input to numeric characters. Mouse-adjustable low-resolution analog values have their own widget, the scrollbar. If you somehow find yourself wishing for a spinbox, use one of those.
- beatgammit 8y ago
  When I'm doing game dev or 3d modeling or something, I often don't care what the values are, I just spin a bit until they look good. The same goes for angles that aren't on a labeled unit circle, percentages, and most other numbers that can reasonably be >30 or so. Basically, if "close-ish" is acceptable, then a numeric input makes a ton of sense. And that's the case for lots of things, and most of those things wouldn't be entered with a keyboard (unless you want to get the figure in the ballpark). If the number is <10 or so most of the time, then a menu makes a ton of sense (number of socks), and include a "custom" option so users can enter their own numbers. I do this with all kinds of things that only need a ballpark number but don't benefit from tweaking (e.g. seconds in an internal; basically, if 10 options or so makes sense, just make it a menu). I happen to work with graphical things that don't need to be precise much of the time but need more precision that a set of presets. But most retail and whatnot apps are not that.
  - thaumasiotes 8y ago
    > that's the case for lots of things, and most of those things wouldn't be entered with a keyboard I agree with that, but this is an attribute of a text entry field. Like I said, we already have a different widget that accommodates the "I don't care what the value is, but I want to be able to easily fudge it upwards or downwards" use case.

by astura 8y ago

deleted 8y ago

[deleted]

benatkin 8y ago

Right, so yes, number shouldn't be used to invoke the numeric keypad. Got it. I agree with another commenter that it would be better if it were called magnitude. Still, even when it's the correct thing to do I still think it's a bad feature because it can be accidentally triggered. There's a gotcha in Safari when using pattern for zipcodes or anything that can have a leading 0: https://www.filamentgroup.com/lab/type-number.html#support-leading-zeros https://www.filamentgroup.com/lab/type-number.html#support-l...

crazygringo 8y ago

So... how are you supposed to trigger a numeric keypad on mobile then, for things that aren't technically a number but are composed entirely of digits? Serious question. Edit: kibibu below says it's the "inputmode" attribute, but it only works in Chrome currently. :( https://html.spec.whatwg.org/multipage/interaction.html#input-modalities%3A-the-inputmode-attribute https://html.spec.whatwg.org/multipage/interaction.html#inpu...

function_seven 8y ago
I use type=“tel” for that. Works better than “number”.
- CivilianZero 8y ago
  Was looking for this to be in the comments somewhere. Thumbs up.

thaumasiotes 8y ago

As far as I can tell, a spinbox interface is not appropriate in any circumstance, even when your semantics are unambiguously numeric. This is mentioned in the article too: "Dammit! I wanted to buy two pairs of socks, not 39." A spinbox only makes sense if you don't care what the value is, such that any two nearby values are exactly equivalent. And that is what the W3 guidance you quote says: > Getting a credit card number wrong by 1 in the last digit isn’t a minor mistake, it’s as wrong as getting every digit incorrect. [And that's why a card number field should not use a spinbox.] This suggests to me that the real problem is the idea that "type=numeric" means you want a spinbox. You don't ever want a spinbox; there's no reason for any attribute to give you one. But you frequently do want to restrict the input to numeric characters. Mouse-adjustable low-resolution analog values have their own widget, the scrollbar. If you somehow find yourself wishing for a spinbox, use one of those.

beatgammit 8y ago
When I'm doing game dev or 3d modeling or something, I often don't care what the values are, I just spin a bit until they look good. The same goes for angles that aren't on a labeled unit circle, percentages, and most other numbers that can reasonably be >30 or so. Basically, if "close-ish" is acceptable, then a numeric input makes a ton of sense. And that's the case for lots of things, and most of those things wouldn't be entered with a keyboard (unless you want to get the figure in the ballpark). If the number is <10 or so most of the time, then a menu makes a ton of sense (number of socks), and include a "custom" option so users can enter their own numbers. I do this with all kinds of things that only need a ballpark number but don't benefit from tweaking (e.g. seconds in an internal; basically, if 10 options or so makes sense, just make it a menu). I happen to work with graphical things that don't need to be precise much of the time but need more precision that a set of presets. But most retail and whatnot apps are not that.
- thaumasiotes 8y ago
  > that's the case for lots of things, and most of those things wouldn't be entered with a keyboard I agree with that, but this is an attribute of a text entry field. Like I said, we already have a different widget that accommodates the "I don't care what the value is, but I want to be able to easily fudge it upwards or downwards" use case.