5 ms·

The problem with this is the browser and desktop environment makers. The correct thing to do is <input type="number"> and it's a reasonable choice even though i

The problem with this is the browser and desktop environment makers. The correct thing to do is <input type="number"> and it's a reasonable choice even though it's not the most optimal UI for your site. If the user encounters it the average Hacker News reading developer's site, it's probably a good thing it was there and not somewhere more critical, so they'll notice and maybe not make the same mistake when they're submitting adoption papers or something. I like the article, and have enjoyed everything I've read that Brad Frost has written, but I will probably keep using <input type="number">. I hope somehow this gets back to browser and desktop environment makers and they fix this usability and accessibility issue.

kibibu 8y ago
The right choice is `inputmode`, which says how to input the value without specifying semantics. https://html.spec.whatwg.org/multipage/interaction.html#input-modalities%3A-the-inputmode-attribute https://html.spec.whatwg.org/multipage/interaction.html#inpu... It'll work in Chrome (and other Blink-based browsers), but nothing else.
- dpwm 8y ago
  > It'll work in Chrome (and other Blink-based browsers), but nothing else. What's interesting is it used to be partially supported in Firefox, and has now been put behind about:config [0]. I'm curious as to why, since the MDN docs seems to endorse its use. [1] [0] https://caniuse.com/#search=inputmode https://caniuse.com/#search=inputmode [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
- efraim 8y ago
  > It'll work in Chrome (and other Blink-based browsers), but nothing else. Then it isn't the right choice.
  - TurningCanadian 8y ago
    It's a progressive enhancement. It doesn't break other browsers.
    - ceejayoz 8y ago
      If the widely supported <input type="tel"> or <input type="phone"> offer a better user experience on average for your users, it's not an enhancement at all. Not yet, at least.
  - benatkin 8y ago
    I just took a close look at the caniuse page [1]. It says that inputmode also works in Mobile Safari on iOS 12.2, which is at Beta 6 [2]. Firefox's mobile market share is 0.58%, and the market share for old versions of Mobile Safari is at 2.51% according to the caniuse page so it's probably not worth waiting on Firefox. I think it will be a good choice very soon, maybe in a couple of months, because it's still possible to enter numbers with the regular keyboard. 1: https://caniuse.com/#search=inputmode https://caniuse.com/#search=inputmode 2: https://en.wikipedia.org/wiki/IOS https://en.wikipedia.org/wiki/IOS (Latest preview in the infobox)
  - Cthulhu_ 8y ago
    Nor is input type="number", given how each OS will offer a different on screen keyboard.
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
blahedo 8y ago
The rule of thumb I teach my students is that it's a number if you plan to do math on it—whether that be incrementing it or multiplying it or making less-than comparisons (with number semantics). If the only thing you ever do with it is use it as a lookup key (or other direct equality comparisons), string might be a better way to think about it. Aside from the input interface issue surfaced in this article, values that are semantically numeric also have the property that they generally can omit leading zeroes (hope you didn't want those New England ZIP codes) or back off to inexact representations when they get large enough (sorry phone numbers whose area code starts with 4 or greater). Yes, you can work around all of these issues by overriding default number behaviour. But some things that look like numbers are really just strings of digits.
- baroffoos 8y ago
  Thats a good rule for dealing with messy real world systems like post codes and phone numbers but its still fine to use numbers in strictly defined non math systems. My database id column uses numbers and I have never had to do math on them other than ordering by id. The only potential issues I would look out for is things where leading zeros could be important and a database would probably drop.
  - rickycook 8y ago
    you increment your database ID for each row... 9-10 is natural for numbers but doesn’t flow for strings. making the number into a string is pointless because it always starts it’s life as a number
    - yen223 8y ago
      What I find most of the time is that you only need IDs to be unique. The fact that databases use auto-incrementing integers to ensure uniqueness is an implementation detail, and not a strictly necessary one (think UUIDs).
      - ryanbrunner 8y ago
robocat 8y ago
Type=number is completely broken on iPad for bank account numbers. An iPad allows spaces and dashes to be typed in, but input.value returns a value of "". Silent failure...
addicted 8y ago
I think the argument that something like a phone “number” or Social Security Number is not actually a number is absolutely valid. If they were numbers, then adding 2 SSNs would have some valid meaning. In reality, adding 2 SSNs is an entirely useless operation. What they are is basically identifiers who happen to restrict the set of allowable characters to digits. One consequence of using input type number on a 2 factor verification code box that I have seen is that the browser would eliminate the leading 0. Which is absolutely the correct behavior if the code was indeed a number, but leads to incorrect behavior since it’s not.

kibibu 8y ago

The right choice is `inputmode`, which says how to input the value without specifying semantics. https://html.spec.whatwg.org/multipage/interaction.html#input-modalities%3A-the-inputmode-attribute https://html.spec.whatwg.org/multipage/interaction.html#inpu... It'll work in Chrome (and other Blink-based browsers), but nothing else.

dpwm 8y ago
> It'll work in Chrome (and other Blink-based browsers), but nothing else. What's interesting is it used to be partially supported in Firefox, and has now been put behind about:config [0]. I'm curious as to why, since the MDN docs seems to endorse its use. [1] [0] https://caniuse.com/#search=inputmode https://caniuse.com/#search=inputmode [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/inputmode https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
efraim 8y ago
> It'll work in Chrome (and other Blink-based browsers), but nothing else. Then it isn't the right choice.
- TurningCanadian 8y ago
  It's a progressive enhancement. It doesn't break other browsers.
  - ceejayoz 8y ago
    If the widely supported <input type="tel"> or <input type="phone"> offer a better user experience on average for your users, it's not an enhancement at all. Not yet, at least.
- benatkin 8y ago
  I just took a close look at the caniuse page [1]. It says that inputmode also works in Mobile Safari on iOS 12.2, which is at Beta 6 [2]. Firefox's mobile market share is 0.58%, and the market share for old versions of Mobile Safari is at 2.51% according to the caniuse page so it's probably not worth waiting on Firefox. I think it will be a good choice very soon, maybe in a couple of months, because it's still possible to enter numbers with the regular keyboard. 1: https://caniuse.com/#search=inputmode https://caniuse.com/#search=inputmode 2: https://en.wikipedia.org/wiki/IOS https://en.wikipedia.org/wiki/IOS (Latest preview in the infobox)
- Cthulhu_ 8y ago
  Nor is input type="number", given how each OS will offer a different on screen keyboard.

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

blahedo 8y ago

The rule of thumb I teach my students is that it's a number if you plan to do math on it—whether that be incrementing it or multiplying it or making less-than comparisons (with number semantics). If the only thing you ever do with it is use it as a lookup key (or other direct equality comparisons), string might be a better way to think about it. Aside from the input interface issue surfaced in this article, values that are semantically numeric also have the property that they generally can omit leading zeroes (hope you didn't want those New England ZIP codes) or back off to inexact representations when they get large enough (sorry phone numbers whose area code starts with 4 or greater). Yes, you can work around all of these issues by overriding default number behaviour. But some things that look like numbers are really just strings of digits.

baroffoos 8y ago
Thats a good rule for dealing with messy real world systems like post codes and phone numbers but its still fine to use numbers in strictly defined non math systems. My database id column uses numbers and I have never had to do math on them other than ordering by id. The only potential issues I would look out for is things where leading zeros could be important and a database would probably drop.
- rickycook 8y ago
  you increment your database ID for each row... 9-10 is natural for numbers but doesn’t flow for strings. making the number into a string is pointless because it always starts it’s life as a number
  - yen223 8y ago
    What I find most of the time is that you only need IDs to be unique. The fact that databases use auto-incrementing integers to ensure uniqueness is an implementation detail, and not a strictly necessary one (think UUIDs).
    - ryanbrunner 8y ago

robocat 8y ago

Type=number is completely broken on iPad for bank account numbers. An iPad allows spaces and dashes to be typed in, but input.value returns a value of "". Silent failure...

addicted 8y ago

I think the argument that something like a phone “number” or Social Security Number is not actually a number is absolutely valid. If they were numbers, then adding 2 SSNs would have some valid meaning. In reality, adding 2 SSNs is an entirely useless operation. What they are is basically identifiers who happen to restrict the set of allowable characters to digits. One consequence of using input type number on a 2 factor verification code box that I have seen is that the browser would eliminate the leading 0. Which is absolutely the correct behavior if the code was indeed a number, but leads to incorrect behavior since it’s not.