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.
>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).
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.
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.
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 -- I eventually had to switch back to number inputs. I couldn't find any other solution that worked.
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.
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.
I'm so confused. I've never wanted the scroll wheel to do anything but zooming on Google Maps. It's not like there is anywhere to scroll to in the first place?
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.
>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.
Maybe you have a small imagination? :)
I use the scroll-to-change-number-input feature quite a lot, for one. Since you have your mouse already in hand, it's faster and more comfortable than switching to keyboard/numpad for quick adjustments or inputting small values; and definitely better than clicking the tiny arrow (does anybody use these anymore?) 32 times or clicking and holding.
I completely disagree. When I see embedded Google Map I always try to zoom it by scrolling, but then get frustrated when it scrolls the page instead and I'm supposed to press control for zooming.
When scroll-wheeling through a KDE/Qt scrollable form, if your mouse cursor happens to land on top of a slider/numeric/dropdown widget, the form will stop scrolling and all scroll inputs will instead scroll the widget.
> 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.
> 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.
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.
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.
>This check is guaranteed to detect any instances where a single character has been omitted, duplicated, mistyped or where two characters have been transposed.
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).
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.
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.
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.
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...
> 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.
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.
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.
[+] [-] benatkin|7 years ago|reply
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.
[+] [-] astura|7 years ago|reply
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).
[+] [-] blahedo|7 years ago|reply
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.
[+] [-] kibibu|7 years ago|reply
https://html.spec.whatwg.org/multipage/interaction.html#inpu...
It'll work in Chrome (and other Blink-based browsers), but nothing else.
[+] [-] addicted|7 years ago|reply
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.
[+] [-] robocat|7 years ago|reply
An iPad allows spaces and dashes to be typed in, but input.value returns a value of "". Silent failure...
[+] [-] dorkwood|7 years ago|reply
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 -- I eventually had to switch back to number inputs. I couldn't find any other solution that worked.
[+] [-] jarfil|7 years ago|reply
[+] [-] crazygringo|7 years ago|reply
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.
[+] [-] mehrdadn|7 years ago|reply
[+] [-] syncsynchalt|7 years ago|reply
[+] [-] lostsock|7 years ago|reply
[+] [-] theon144|7 years ago|reply
Maybe you have a small imagination? :)
I use the scroll-to-change-number-input feature quite a lot, for one. Since you have your mouse already in hand, it's faster and more comfortable than switching to keyboard/numpad for quick adjustments or inputting small values; and definitely better than clicking the tiny arrow (does anybody use these anymore?) 32 times or clicking and holding.
[+] [-] xaphod|7 years ago|reply
[+] [-] _fbpt|7 years ago|reply
I reported this at https://bugs.kde.org/show_bug.cgi?id=399324, and several Reddit posts have complained about the same thing.
This issue may also apply to GTK.
[+] [-] davvolun|7 years ago|reply
I'll admit, I prefer something like CTRL+<scroll> or something to trigger it as an alternative behavior, but that's a minor qualm, really.
[+] [-] BurningFrog|7 years ago|reply
[+] [-] LukaD|7 years ago|reply
[+] [-] davvolun|7 years ago|reply
> 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.
[+] [-] sebazzz|7 years ago|reply
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|7 years ago|reply
[+] [-] josefresco|7 years ago|reply
Sounds like your problem is your "magic" mouse.
[+] [-] atomwaffel|7 years ago|reply
[+] [-] thomasedwards|7 years ago|reply
[+] [-] ty___ler|7 years ago|reply
[+] [-] jimmaswell|7 years ago|reply
[+] [-] ohazi|7 years ago|reply
[+] [-] jwr|7 years ago|reply
[for the pedants/purists: yes, there is a chance that your mistake will just happen to hit the same checksum]
[+] [-] stackola|7 years ago|reply
https://en.wikipedia.org/wiki/International_Bank_Account_Num...
[+] [-] EADGBE|7 years ago|reply
[+] [-] scarejunba|7 years ago|reply
[+] [-] beatgammit|7 years ago|reply
[+] [-] zhte415|7 years ago|reply
[+] [-] thomasedwards|7 years ago|reply
[+] [-] Cthulhu_|7 years ago|reply
[+] [-] carmate383|7 years ago|reply
https://imgur.com/a/QHtfBKn
[+] [-] robocat|7 years ago|reply
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.
[+] [-] cowb0yl0gic|7 years ago|reply
[+] [-] 33degrees|7 years ago|reply
[+] [-] jeswin|7 years ago|reply
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|7 years ago|reply
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.
[+] [-] kgwxd|7 years ago|reply
[+] [-] _ZeD_|7 years ago|reply
[+] [-] ferongr|7 years ago|reply
[+] [-] jitl|7 years ago|reply
[+] [-] kqr|7 years ago|reply
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|7 years ago|reply