8 ms·

You probably don’t need input type=“number”

145 points by shripadk 8y ago

benatkin 8y ago
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.
jitl 8y ago
Sounds like it should be <input type=“magnitude” /> or <input pattern=“...” />
ty___ler 8y ago
My favorite input type=number quirk is you can type the letter ‘e’ into it for compatibility with scientific notation!
- jimmaswell 8y ago
  An additional reason not to use type=number just because something is only made up of numbers. Good thing we have the pattern attribute.
marcell 8y ago
I thought the general recommendation was to use type=“tel” to pull up the 9 digit keypad
sbr464 8y ago
Kind of a workaround, but if you desired the feature to enable loading the numpad keyboard on mobile or onscreen accessible keyboard, etc, could you possibly override the on-scroll handlers, preventDefault etc?
- yefim 8y ago
  Yep, it's possible. Looks like you need to prevent the default behavior of the wheel event. Here's a quick example I whipped up: https://codepen.io/yefim/pen/drroer https://codepen.io/yefim/pen/drroer and here's a 5 year old Stack Overflow answer about it: https://stackoverflow.com/a/14810932/597260 https://stackoverflow.com/a/14810932/597260
  - sbr464 8y ago
    Thanks for sharing.
EADGBE 8y ago
I learned a general rule about numbers vs strings, and I think it’d apply in this example as well: if you aren’t doing math with it, keep it a string. (Phone numbers, numeric postal codes, account numbers, house numbers, etc).
- beatgammit 8y ago
  And if there's only 10 or so reasonable/acceptable options, it should probably just be a menu instead.
- zhte415 8y ago
  What led you to that general rule?
- scarejunba 8y ago
  Don’t leak your data model, though. Having mobile users have the number pad pop up is absolutely the right answer. Treating it as a generic string is an incredibly annoying UX failure. The fact that spinwheels by default on this thing is another UX failure.
crazygringo 8y ago
Ugh. Can I just say that using the scroll wheel for anything but scrolling is one of my all-time UX pet peeves. Probably #1, in fact. Above all, Google Maps repurposing it for zoom. Like, I'm scrolling down a webpage, there's an embedded Google Map, and suddenly it stops scrolling and starts zooming in by orders of magnitude and it's just a WTF moment... you're breaking the web. Nobody wants to zoom by orders of magnitude like that. Nobody asked you to stop scrolling the page. It's beyond useless. Likewise, this is doing the same for numbers, at least in Safari. Again, nobody wants that. I can't think of any good reason ever to have that as a "feature". I can't even imagine what goes through the minds of people who think that's a good idea. Worst. Design. Decision. Ever.
- syncsynchalt 8y ago
  In my experience Google Maps fixed embedded maps about a year ago, it requires command-scroll to zoom and otherwise scrolls normally. I didn't realize that might be browser-specific, I'm using macos + safari.
  - crazygringo 8y ago
    Son of a gun. So for embedded maps, it only took them 13 years to fix, from 2005 to 2018. Better late than never, I suppose. However, it still doesn't change the fact that, on my Mac, on Google Maps proper I want to use scroll wheel or two-finger swipe equivalent to pan/scroll up-down or side-to-side like virtually every other app does, instead of zooming like virtually no other app does.
    - joshuamorton 8y ago
      I think this is unique to you. Click + drag to pan and scroll to zoom has been the way maps work for as long as I can remember. Having the scroll wheel move in y with no scroll to move in x just seems...weird.
      - lstamour 8y ago
        Ah, you should’ve seen what we had before Google Maps — https://images.app.goo.gl/JQ5xAhP8HpZjRNby7 https://images.app.goo.gl/JQ5xAhP8HpZjRNby7 The map was a static image, you had to click to change zoom levels and wait for the entire page to reload, or click to move in a cardinal direction and then agonizingly wait for the page to reload. The idea you could have infinite scrolling tiles of map with a simple way to map directions that auto-completed street names parsing from a plain English search — that was basically a revelation. :) Though MapQuest did give decent directions and a nice overview of where you were going. Before that, you had to buy a book every year to keep in a glove compartment and look up street names in an alphabetical index, then go to a page number, look for a row and column and then plot a route by flipping between many pages or having traveled there before (aka getting lost) https://images.app.goo.gl/SdS9Z1rfs3HPJJwA9 https://images.app.goo.gl/SdS9Z1rfs3HPJJwA9 Also a Google Maps innovation—trying to accurately put street numbers on a map. You’d often know, in some books, where street numbers began and ended at intersections, but it was extra detail and was often left out or entirely wrong. Of course it’s still wrong today, but street view really changed all that.
33degrees 8y ago
I ran into this on a site a while back, I believe it was for a health insurance claim. There was JS on the page that was interacting with a number input and making the form impossible to fill in properly; I had to use the inspector to change the input type to get it working. I wonder how many people simply gave up when confronted with the problem...
carmate383 8y ago
OP probably doesn't need those stupid circle graphics that make reading the article title impossible to read. https://imgur.com/a/QHtfBKn https://imgur.com/a/QHtfBKn
dorkwood 8y ago
Input type="number" is the only way to get a numeric keyboard that supports floating point numbers on iOS. The "pattern" trick gives you nice big numbers, but no decimal point. Apparently, the "inputmode" property will solve this in the future, but it doesn't yet. I learnt this the hard way while trying to get my text input fields to show the correct numeric keyboard on this site: https://percentagecalculatortools.com https://percentagecalculatortools.com -- I eventually had to switch back to number inputs. I couldn't find any other solution that worked.
- jarfil 8y ago
  On the bright side, it's probably less likely to have an input impacted by a mouse wheel on mobile, so just changing the input type between mobile and desktop might be good enough.
jeswin 8y ago
> While input type="number triggers numeric keyboards on touchscreens leading to better mobile UX, that can also be accomplished by configuring the pattern attribute in a certain way. Sorry, it's silly to propose features which work only on iOS. Standards-wise, I am not even sure if browsers should be parsing regex to accomplish this goal. Input type=number can just be about what keypad to show, and shed the up-down arrows for increment/decrement. That's a valid complaint.
- ketzu 8y ago
  The linked article in the post especially specifies that it doesn't work well at all and has it's own limitations and recommends using pattern + type=number together and then adds like a ton of workarounds on top of that. The pattern trick article basically explains the exact opposite of what the "you don't need input type number" article says but is cited for something it does not say at all.
deleted 8y ago
[deleted]
sebazzz 8y ago
> Certainly not for account numbers, social security numbers, credit card numbers, confirmation numbers, and others. Those are not numbers. Those are opaque identifiers which just happen to take a form of a number. My DBA teacher always said: If you don't need to calculate it, then don't process and store it as a number. This applies to phone numbers as well.
- adrr 8y ago
  Strings take so much more space than a number. This is why you store IPV5 as numbers and not strings unless you want a very large table.
  - thomasedwards 8y ago
    What happens when you convert 00000456 to an integer? Strings are safer, which is more important than space.
  - tbyehl 8y ago
    An IP address is actually a number that math may be performed upon.
superasn 8y ago
Input number also doesn't give a very good experience on mobiles too for the reason that at least google keyboard hides autocomplete suggestions for me. The most common number input I do is enter my mobile number and it would be lovely to have autocomplete fill it. By the way I found typing hero on android just for this. It's a fantastic app for entering numbers and expanding short cuts on android!
- photonios 8y ago
  Isn't type=number not at all suited for phone numbers? It might work for local numbers, but the common E.164 recommendation allows for a leading `+`. type=tel [1] seems a lot more suited for this. [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/tel https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
beatgammit 8y ago
One pretty stupid reason I have for it is that Angular used to (still does?) automatically converts number inputs to numbers in the data binding layer, which is nice sometimes. It's not a very good reason, but it's a reason nonetheless. Now that I'm using React, I try to use the best type for the UX since I have to do it manually anyway, but with Angular it was sometimes easier to use the slightly worse UX.
ohazi 8y ago
The ball on the magic mouse is particularly twitchy, and doesn't give back any sort of feedback. There are lots of other reasons why that particular mouse is an ergonomic nightmare, but I think this aspect is what caused the author to not notice the number change.
_ZeD_ 8y ago
so... the real problem is the crappy apple's magic mouse?
- ferongr 8y ago
  Yes, but everybody is (deliberately?) ignoring that point.
  - f055 8y ago
    That mouse scroll is "clever", but for accurate input a regular scroll wheel is so much better.
robocat 8y ago
pattern=/d* or =[0-9]* no longer works in iOS 12.2 beta. inputmode is supposed to work in Mobile Safari on iOS 12.2 type=number acts differently between iPhone and iPad. And on an IPad if you type in anything that isn't a number, it silently fails (value==""). type=tel works ok, but at some point will have a popup to select from contacts or autofill. Data input is essentially broken on browsers from anything more complex than a text field.
josefresco 8y ago
>I quickly refocused into the field and slightly moved my index finger up on my Magic Mouse. Sounds like your problem is your "magic" mouse.
- thomasedwards 8y ago
  ...or any touch-pad or touch-mouse? Or really any device that scrolls?
  - anoncake 8y ago
    I have never accidentally scrolled with either a touchpad or a normal mouse.
  - pavel_lishin 8y ago
    My macbook's touchpad doesn't seem to increment or decrement a type="number" input when I try to scroll within it.
    - dalore 8y ago
      Try a standard html input, some websites hijack the input to stop this behaviour.
      - pavel_lishin 8y ago
        I created an html file with only a <input type="number"> element in it.
        thomasedwards 8y ago
        Yeah I looked into also, it appears to pretty much just be Chrome.
- atomwaffel 8y ago
  It’s really not though, or at least not the only problem. <input type="number"> has some additional behaviour that makes it inappropriate for phone or account numbers or anything you wouldn’t store in a numeric data type: many browsers will strip leading zeroes; they may display stepper buttons; on-screen keyboards will offer a decimal point (and/or comma, depending on the locale); and something like 1.42e-60 is valid input as far as the browser is concerned.
thomasedwards 8y ago
I agree with his point, account numbers aren’t numbers. Say your account number is 000345. That’s not a number.
- Cthulhu_ 8y ago
  That's something I think most developers will at some point in their career run into - it's probably in a "Misconceptions developers have about x" kind of post. I mean a phone number looks like a number but if it has a 0 prefix information will be filtered out.
kqr 8y ago
> “Oooohh, so things like account numbers and social security numbers aren’t really ‘numbers'”. This seems surprisingly insightful for a non-programmer! Either OP is a good explainer, or the support person is one the bank should hold on to.
- notjustanymike 8y ago
  OP in this case being Brad Frost, one of the more influential members of the web community.
smoser 8y ago
AKA: Chrome’s poor design choice to allow the value of input type=number to change (without warning) on scroll. Safari of course doesn’t have this problem.
LukaD 8y ago
For crying out loud, input type="number" is fine. Please don't stop using it. The problem here is a bad input device.
- davvolun 8y ago
  No, disagree. > input type="number" is fine. Please don't stop using it. Agreed > The problem here is a bad input device Part of the problem is the input device, but, as is stated around here, a "Social Security Number" is NOT a number. A number is an object that we can reasonably expect +-*/ operations on, within the context of mathematical feasibility (i.e., yes, there are some issues with division under the integer set). I saw stated elsewhere something like, a Social Security Number is an identifier which happens to be limited to [0-9]. It should be treated as such -- an input field with a limitation on valid characters. Same with a phone number or a membership ID. No matter how sensitive the input wheel, you should not use input type="number" for a non-number, no matter how much it really, really looks like a number.
jwr 8y ago
As a side note, EU account numbers include a built-in checksum, so you can detect right away if the account number is correct or not. [for the pedants/purists: yes, there is a chance that your mistake will just happen to hit the same checksum]
- stackola 8y ago
  >This check is guaranteed to detect any instances where a single character has been omitted, duplicated, mistyped or where two characters have been transposed. https://en.wikipedia.org/wiki/International_Bank_Account_Number#Check_digits https://en.wikipedia.org/wiki/International_Bank_Account_Num...
Kusse 8y ago
"Thanks, Brad!"
kgwxd 8y ago
I've never even thought to test the scroll behavior on input number. Win Forms and browsers used to do that on select boxes too. Win forms still requires a hack, but browsers fixed that long ago. Why on earth did they think it was a good idea for any other input? It's especially problematic on any view that scrolls, it's easy to accidentally land on the input and not even notice you changed the value.
some1else 8y ago
I'd suggest that you don't need input type='number' where the number is an identifier, not a quantity. However, that would put mobile users at a disadvantage, because they'd have to switch to the numeric keyboard manually. The input device is also not at fault here. It's the browser vendor's implementation of the number field that isn't optimal.
- frosted-flakes 8y ago
  You can specify the pattern attribute to be only numeric digits with "\d" .
cowb0yl0gic 8y ago
As a data manager and a database developer, I can assure you there is a big difference between "a number" and "a string of digits" (even when those digits are supposed to be a number). It's a sign of poor database design when a field type of numeric is chosen because something "looks like a number". Usually, I would only use an integer field for something like an internal record ID or lookup code, whereas an external-facing ID should be a string, enforced by a mask or limited input set. Often, as a database evolves, what starts out as a numeric ID ("Customer 1"!) can evolve into something more complex ("Let's prepend a geographic code to segment our ID space!"), which cascades through the entire application stack. It's important for a UI developer to really understand what the data domain is, rather than just blindly following the underlying data type, and to help ensure that the user is guided properly.
Albert500 8y ago
I’m Albert a hacker who has built a very good reputation and undeniably one of the best hackers you can come across.i have got access to hack into any account and also get to generate passwords for accounts like Facebook,Instagram,Twitter,gmail,yahoo mail,whats-app,we-chat,etc.Retrieving hacked social media accounts,clearing criminal records,increase credit scores,CC hack,hack bank accounts for transfers and credit card top ups,application hacking.We do custom software and web development in php, java, asp.net etc.hacking computer systems,Website hack,Catch hacker scammers,Phishing emails, that's to mention a few.You can contact me on. Email ... Theredhackergroup@gmail.com Whatsapp...+17867089974 or TEXT:571 318 9498 Best Online hacker with 100% guarantee and money back return policy for 48hours.

145 points by shripadk 8y ago

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.

jitl 8y ago

Sounds like it should be <input type=“magnitude” /> or <input pattern=“...” />

ty___ler 8y ago

My favorite input type=number quirk is you can type the letter ‘e’ into it for compatibility with scientific notation!

jimmaswell 8y ago
An additional reason not to use type=number just because something is only made up of numbers. Good thing we have the pattern attribute.

marcell 8y ago

I thought the general recommendation was to use type=“tel” to pull up the 9 digit keypad

sbr464 8y ago

Kind of a workaround, but if you desired the feature to enable loading the numpad keyboard on mobile or onscreen accessible keyboard, etc, could you possibly override the on-scroll handlers, preventDefault etc?

yefim 8y ago
Yep, it's possible. Looks like you need to prevent the default behavior of the wheel event. Here's a quick example I whipped up: https://codepen.io/yefim/pen/drroer https://codepen.io/yefim/pen/drroer and here's a 5 year old Stack Overflow answer about it: https://stackoverflow.com/a/14810932/597260 https://stackoverflow.com/a/14810932/597260
- sbr464 8y ago
  Thanks for sharing.

EADGBE 8y ago

I learned a general rule about numbers vs strings, and I think it’d apply in this example as well: if you aren’t doing math with it, keep it a string. (Phone numbers, numeric postal codes, account numbers, house numbers, etc).

beatgammit 8y ago
And if there's only 10 or so reasonable/acceptable options, it should probably just be a menu instead.
zhte415 8y ago
What led you to that general rule?
scarejunba 8y ago
Don’t leak your data model, though. Having mobile users have the number pad pop up is absolutely the right answer. Treating it as a generic string is an incredibly annoying UX failure. The fact that spinwheels by default on this thing is another UX failure.

crazygringo 8y ago

Ugh. Can I just say that using the scroll wheel for anything but scrolling is one of my all-time UX pet peeves. Probably #1, in fact. Above all, Google Maps repurposing it for zoom. Like, I'm scrolling down a webpage, there's an embedded Google Map, and suddenly it stops scrolling and starts zooming in by orders of magnitude and it's just a WTF moment... you're breaking the web. Nobody wants to zoom by orders of magnitude like that. Nobody asked you to stop scrolling the page. It's beyond useless. Likewise, this is doing the same for numbers, at least in Safari. Again, nobody wants that. I can't think of any good reason ever to have that as a "feature". I can't even imagine what goes through the minds of people who think that's a good idea. Worst. Design. Decision. Ever.

syncsynchalt 8y ago
In my experience Google Maps fixed embedded maps about a year ago, it requires command-scroll to zoom and otherwise scrolls normally. I didn't realize that might be browser-specific, I'm using macos + safari.
- crazygringo 8y ago
  Son of a gun. So for embedded maps, it only took them 13 years to fix, from 2005 to 2018. Better late than never, I suppose. However, it still doesn't change the fact that, on my Mac, on Google Maps proper I want to use scroll wheel or two-finger swipe equivalent to pan/scroll up-down or side-to-side like virtually every other app does, instead of zooming like virtually no other app does.
  - joshuamorton 8y ago
    I think this is unique to you. Click + drag to pan and scroll to zoom has been the way maps work for as long as I can remember. Having the scroll wheel move in y with no scroll to move in x just seems...weird.
    - lstamour 8y ago
      Ah, you should’ve seen what we had before Google Maps — https://images.app.goo.gl/JQ5xAhP8HpZjRNby7 https://images.app.goo.gl/JQ5xAhP8HpZjRNby7 The map was a static image, you had to click to change zoom levels and wait for the entire page to reload, or click to move in a cardinal direction and then agonizingly wait for the page to reload. The idea you could have infinite scrolling tiles of map with a simple way to map directions that auto-completed street names parsing from a plain English search — that was basically a revelation. :) Though MapQuest did give decent directions and a nice overview of where you were going. Before that, you had to buy a book every year to keep in a glove compartment and look up street names in an alphabetical index, then go to a page number, look for a row and column and then plot a route by flipping between many pages or having traveled there before (aka getting lost) https://images.app.goo.gl/SdS9Z1rfs3HPJJwA9 https://images.app.goo.gl/SdS9Z1rfs3HPJJwA9 Also a Google Maps innovation—trying to accurately put street numbers on a map. You’d often know, in some books, where street numbers began and ended at intersections, but it was extra detail and was often left out or entirely wrong. Of course it’s still wrong today, but street view really changed all that.

33degrees 8y ago

I ran into this on a site a while back, I believe it was for a health insurance claim. There was JS on the page that was interacting with a number input and making the form impossible to fill in properly; I had to use the inspector to change the input type to get it working. I wonder how many people simply gave up when confronted with the problem...

carmate383 8y ago

OP probably doesn't need those stupid circle graphics that make reading the article title impossible to read. https://imgur.com/a/QHtfBKn https://imgur.com/a/QHtfBKn

dorkwood 8y ago

Input type="number" is the only way to get a numeric keyboard that supports floating point numbers on iOS. The "pattern" trick gives you nice big numbers, but no decimal point. Apparently, the "inputmode" property will solve this in the future, but it doesn't yet. I learnt this the hard way while trying to get my text input fields to show the correct numeric keyboard on this site: https://percentagecalculatortools.com https://percentagecalculatortools.com -- I eventually had to switch back to number inputs. I couldn't find any other solution that worked.

jarfil 8y ago
On the bright side, it's probably less likely to have an input impacted by a mouse wheel on mobile, so just changing the input type between mobile and desktop might be good enough.

jeswin 8y ago

> While input type="number triggers numeric keyboards on touchscreens leading to better mobile UX, that can also be accomplished by configuring the pattern attribute in a certain way. Sorry, it's silly to propose features which work only on iOS. Standards-wise, I am not even sure if browsers should be parsing regex to accomplish this goal. Input type=number can just be about what keypad to show, and shed the up-down arrows for increment/decrement. That's a valid complaint.

ketzu 8y ago
The linked article in the post especially specifies that it doesn't work well at all and has it's own limitations and recommends using pattern + type=number together and then adds like a ton of workarounds on top of that. The pattern trick article basically explains the exact opposite of what the "you don't need input type number" article says but is cited for something it does not say at all.

deleted 8y ago

[deleted]

sebazzz 8y ago

> Certainly not for account numbers, social security numbers, credit card numbers, confirmation numbers, and others. Those are not numbers. Those are opaque identifiers which just happen to take a form of a number. My DBA teacher always said: If you don't need to calculate it, then don't process and store it as a number. This applies to phone numbers as well.

adrr 8y ago
Strings take so much more space than a number. This is why you store IPV5 as numbers and not strings unless you want a very large table.
- thomasedwards 8y ago
  What happens when you convert 00000456 to an integer? Strings are safer, which is more important than space.
- tbyehl 8y ago
  An IP address is actually a number that math may be performed upon.

superasn 8y ago

Input number also doesn't give a very good experience on mobiles too for the reason that at least google keyboard hides autocomplete suggestions for me. The most common number input I do is enter my mobile number and it would be lovely to have autocomplete fill it. By the way I found typing hero on android just for this. It's a fantastic app for entering numbers and expanding short cuts on android!

photonios 8y ago
Isn't type=number not at all suited for phone numbers? It might work for local numbers, but the common E.164 recommendation allows for a leading `+`. type=tel [1] seems a lot more suited for this. [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/tel https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...

beatgammit 8y ago

One pretty stupid reason I have for it is that Angular used to (still does?) automatically converts number inputs to numbers in the data binding layer, which is nice sometimes. It's not a very good reason, but it's a reason nonetheless. Now that I'm using React, I try to use the best type for the UX since I have to do it manually anyway, but with Angular it was sometimes easier to use the slightly worse UX.

ohazi 8y ago

The ball on the magic mouse is particularly twitchy, and doesn't give back any sort of feedback. There are lots of other reasons why that particular mouse is an ergonomic nightmare, but I think this aspect is what caused the author to not notice the number change.

_ZeD_ 8y ago

so... the real problem is the crappy apple's magic mouse?

ferongr 8y ago
Yes, but everybody is (deliberately?) ignoring that point.
- f055 8y ago
  That mouse scroll is "clever", but for accurate input a regular scroll wheel is so much better.

robocat 8y ago

pattern=/d* or =[0-9]* no longer works in iOS 12.2 beta. inputmode is supposed to work in Mobile Safari on iOS 12.2 type=number acts differently between iPhone and iPad. And on an IPad if you type in anything that isn't a number, it silently fails (value==""). type=tel works ok, but at some point will have a popup to select from contacts or autofill. Data input is essentially broken on browsers from anything more complex than a text field.

josefresco 8y ago

>I quickly refocused into the field and slightly moved my index finger up on my Magic Mouse. Sounds like your problem is your "magic" mouse.

thomasedwards 8y ago
...or any touch-pad or touch-mouse? Or really any device that scrolls?
- anoncake 8y ago
  I have never accidentally scrolled with either a touchpad or a normal mouse.
- pavel_lishin 8y ago
  My macbook's touchpad doesn't seem to increment or decrement a type="number" input when I try to scroll within it.
  - dalore 8y ago
    Try a standard html input, some websites hijack the input to stop this behaviour.
    - pavel_lishin 8y ago
      I created an html file with only a <input type="number"> element in it.
      - thomasedwards 8y ago
        Yeah I looked into also, it appears to pretty much just be Chrome.
atomwaffel 8y ago
It’s really not though, or at least not the only problem. <input type="number"> has some additional behaviour that makes it inappropriate for phone or account numbers or anything you wouldn’t store in a numeric data type: many browsers will strip leading zeroes; they may display stepper buttons; on-screen keyboards will offer a decimal point (and/or comma, depending on the locale); and something like 1.42e-60 is valid input as far as the browser is concerned.

thomasedwards 8y ago

I agree with his point, account numbers aren’t numbers. Say your account number is 000345. That’s not a number.

Cthulhu_ 8y ago
That's something I think most developers will at some point in their career run into - it's probably in a "Misconceptions developers have about x" kind of post. I mean a phone number looks like a number but if it has a 0 prefix information will be filtered out.

kqr 8y ago

> “Oooohh, so things like account numbers and social security numbers aren’t really ‘numbers'”. This seems surprisingly insightful for a non-programmer! Either OP is a good explainer, or the support person is one the bank should hold on to.

notjustanymike 8y ago
OP in this case being Brad Frost, one of the more influential members of the web community.

smoser 8y ago

AKA: Chrome’s poor design choice to allow the value of input type=number to change (without warning) on scroll. Safari of course doesn’t have this problem.

LukaD 8y ago

For crying out loud, input type="number" is fine. Please don't stop using it. The problem here is a bad input device.

davvolun 8y ago
No, disagree. > input type="number" is fine. Please don't stop using it. Agreed > The problem here is a bad input device Part of the problem is the input device, but, as is stated around here, a "Social Security Number" is NOT a number. A number is an object that we can reasonably expect +-*/ operations on, within the context of mathematical feasibility (i.e., yes, there are some issues with division under the integer set). I saw stated elsewhere something like, a Social Security Number is an identifier which happens to be limited to [0-9]. It should be treated as such -- an input field with a limitation on valid characters. Same with a phone number or a membership ID. No matter how sensitive the input wheel, you should not use input type="number" for a non-number, no matter how much it really, really looks like a number.

jwr 8y ago

As a side note, EU account numbers include a built-in checksum, so you can detect right away if the account number is correct or not. [for the pedants/purists: yes, there is a chance that your mistake will just happen to hit the same checksum]

stackola 8y ago
>This check is guaranteed to detect any instances where a single character has been omitted, duplicated, mistyped or where two characters have been transposed. https://en.wikipedia.org/wiki/International_Bank_Account_Number#Check_digits https://en.wikipedia.org/wiki/International_Bank_Account_Num...

Kusse 8y ago

"Thanks, Brad!"

kgwxd 8y ago

I've never even thought to test the scroll behavior on input number. Win Forms and browsers used to do that on select boxes too. Win forms still requires a hack, but browsers fixed that long ago. Why on earth did they think it was a good idea for any other input? It's especially problematic on any view that scrolls, it's easy to accidentally land on the input and not even notice you changed the value.

some1else 8y ago

I'd suggest that you don't need input type='number' where the number is an identifier, not a quantity. However, that would put mobile users at a disadvantage, because they'd have to switch to the numeric keyboard manually. The input device is also not at fault here. It's the browser vendor's implementation of the number field that isn't optimal.

frosted-flakes 8y ago
You can specify the pattern attribute to be only numeric digits with "\d" .

cowb0yl0gic 8y ago

As a data manager and a database developer, I can assure you there is a big difference between "a number" and "a string of digits" (even when those digits are supposed to be a number). It's a sign of poor database design when a field type of numeric is chosen because something "looks like a number". Usually, I would only use an integer field for something like an internal record ID or lookup code, whereas an external-facing ID should be a string, enforced by a mask or limited input set. Often, as a database evolves, what starts out as a numeric ID ("Customer 1"!) can evolve into something more complex ("Let's prepend a geographic code to segment our ID space!"), which cascades through the entire application stack. It's important for a UI developer to really understand what the data domain is, rather than just blindly following the underlying data type, and to help ensure that the user is guided properly.

Albert500 8y ago

I’m Albert a hacker who has built a very good reputation and undeniably one of the best hackers you can come across.i have got access to hack into any account and also get to generate passwords for accounts like Facebook,Instagram,Twitter,gmail,yahoo mail,whats-app,we-chat,etc.Retrieving hacked social media accounts,clearing criminal records,increase credit scores,CC hack,hack bank accounts for transfers and credit card top ups,application hacking.We do custom software and web development in php, java, asp.net etc.hacking computer systems,Website hack,Catch hacker scammers,Phishing emails, that's to mention a few.You can contact me on. Email ... Theredhackergroup@gmail.com Whatsapp...+17867089974 or TEXT:571 318 9498 Best Online hacker with 100% guarantee and money back return policy for 48hours.