
You probably don’t need input type=“number” - shripadk
http://bradfrost.com/blog/post/you-probably-dont-need-input-typenumber/
======
benatkin
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.

~~~
astura
Well... The spec actually says it's not the "correct" thing to do

[https://www.w3.org/TR/html5/forms.html#number-
state-(type=nu...](https://www.w3.org/TR/html5/forms.html#number-
state-\(type=number\))

>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).

~~~
thaumasiotes
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
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
> 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.

~~~
zeroimpl
Is there an <input type=“scrollbar”/>?

Also, input does not necessarily mean text entry. We have <input
type=“checkbox”/> and <input type=“button”/> among others.

~~~
yorwba
I'm not sure what you mean by "scrollbar" input, but maybe <input
type="range"> fits?

------
dorkwood
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
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.

------
crazygringo
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.

~~~
mehrdadn
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?

~~~
edoceo
On Maps prime site it makes sense, embedded on other pages it makes less
sense. But, the page other needs to add one line of config, or G needs to
change defaults for embedded

~~~
mehrdadn
But even when I'm on an embedded map it's super annoying to have to hold
control... I pretty much never want to scroll if my mouse is hovering over the
map. It's how it works in every application isn't it? Scrolling while hovering
affects the object under the cursor, not the object with the focus. I feel
like it might be better if the page has logic that checks "if you're already
scrolling, then keep scrolling the same object instead of shifting focus to
the embedded map"?

~~~
hosay123
I have yet to encounter an embedded map that could not have better been

\- a static image

\- a table of addresses with an external map link

It's not just the idea of wheeling around in some 256x256 box added at the
last minute to a Contact Us page, the entire concept of an embeddable map is
shit

Their main purpose seems to be to add 1 second to page loads across the web,
and feed more clickstream back to the mothership

The main exception to this I can think of right now is Flightaware, but even
that does not require such detailed rendering

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

~~~
davvolun
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.

------
sebazzz
> 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
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
What happens when you convert 00000456 to an integer? Strings are safer, which
is more important than space.

------
josefresco
>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
...or any touch-pad or touch-mouse? Or really any device that scrolls?

~~~
pavel_lishin
My macbook's touchpad doesn't seem to increment or decrement a type="number"
input when I try to scroll within it.

~~~
dalore
Try a standard html input, some websites hijack the input to stop this
behaviour.

~~~
pavel_lishin
I created an html file with only a

    
    
        <input type="number">
    

element in it.

~~~
thomasedwards
Yeah I looked into also, it appears to pretty much just be Chrome.

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

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

------
ohazi
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.

------
jwr
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
>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_Num...](https://en.wikipedia.org/wiki/International_Bank_Account_Number#Check_digits)

------
EADGBE
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).

~~~
scarejunba
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.

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

~~~
Cthulhu_
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.

------
carmate383
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)

------
robocat
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.

------
cowb0yl0gic
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.

------
33degrees
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...

------
jeswin
> 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
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.

------
kgwxd
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.

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

~~~
ferongr
Yes, but everybody is (deliberately?) ignoring that point.

~~~
f055
That mouse scroll is "clever", but for accurate input a regular scroll wheel
is so much better.

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

------
kqr
> “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
OP in this case being Brad Frost, one of the more influential members of the
web community.

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

------
beatgammit
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.

------
some1else
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
You can specify the pattern attribute to be only numeric digits with "\d" .

------
superasn
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
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/in...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/input/tel)

------
sbr464
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
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
Thanks for sharing.

------
smoser
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.

------
Kusse
"Thanks, Brad!"

