You probably don’t need input type=“number” | Hacker News Reader

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

bradfrost.com

145 pointsshripadk116 comments

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 right choice is `inputmode`, which says how to input the value without specifying semantics.

https://html.spec.whatwg.org/multipage/interaction.html#inpu...

It'll work in Chrome (and other Blink-based browsers), but nothing else.

> 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

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

> It'll work in Chrome (and other Blink-based browsers), but nothing else.

Then it isn't the right choice.

It's a progressive enhancement. It doesn't break other browsers.

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.

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

2: https://en.wikipedia.org/wiki/IOS (Latest preview in the infobox)

Nor is input type="number", given how each OS will offer a different on screen keyboard.

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

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

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

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#inpu...

I use type=“tel” for that. Works better than “number”.

Was looking for this to be in the comments somewhere. Thumbs up.

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.

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.

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

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.

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

That’s not what the W3 line you quoted is saying, you’re conflating two different things. The W3 guidance is making a distinction between numeric values and identifiers that happen to use all digits; it’s a semantic difference.

Some people do like spin boxes, and they allow you to adjust numeric values without reaching for the digit row on your keyboard. By all means, don’t use them if you don’t like them, but they do exist for a reason.

Whether spinboxes are good UI is a separate debate.

Why wouldn't I want a spinbox for something like product quantity? I didn't really understand the example in the article. I get that it doesn't help if I mistype 39 when I meant 2, but is helpful in other cases.

If I'm not mistaken, using type="pattern" also means I can't use min or max.

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.

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.

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

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

Right, but I think the main point is if you're going to use auto-incrementation to provide values for your IDs, you might as well use numbers, since at that point you are doing math on them (one super simple operation of "+1", but math nonetheless.)

If you use UUIDs you can have clients distributed around generate IDs for the db before they even save, no need for a +1 centralized id mechanism. That becomes a bottleneck.

I seem to recall a recent discussion pointing out an issue with leading zeros in IP addresses being interpreted as Octal, leading to possible invalid addresses like 09.09.09.09 (9 isn't valid Octal).

So just because something looks like a number doesn't mean that you can do 'safe' things like add leading zeros.

> I seem to recall a recent discussion pointing out an issue with leading zeros in IP addresses being interpreted as Octal, leading to possible invalid addresses like 09.09.09.09 (9 isn't valid Octal).

That looks like a framework-specific issue and if that’s how you process incoming numbers from the Internet, you are clearly doing something wrong.

Anyone on the Internet will reasonably expect that a decimal number provided to a Internet input-field will be interpreted as a decimal number.

Anything else, unless explicitly stated, is by definition an error on the part of the application developer.

The person concerned was inserting leading zeros so that the numbers lined up nicely, IIRC

Similar to the rule of thumb I use: if adding 1 to the number gives you anything meaningful its a number.

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

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.

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.

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.

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.

Ah, you should’ve seen what we had before Google Maps — 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

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.

Should clarify: I have used an atlas (in fact I had one in my car in 2018 when I sold it), but internet maps have always used that interface, though I do remember that mapquest interface and the similar interface on tribalwars.net before it updated to use js and click+drag map scrolling.

If you want some nostalgia, StreetMap is still just as it was in 2002 or whatever.

This alone convinced my father that it was worth having Internet access at home.

http://streetmap.co.uk/map.srf?x=531500&y=181500&z=120&sv=Lo...

> Having the scroll wheel move in y with no scroll to move in x just seems...weird.

Shift+scroll works as horizontal scroll in just about every place I've had reason to try it. (Outside of browsers, at least, though there I'm uncertain because everyone puts so much effort into eliminating any horizontal scroll)

Shift + scroll wheel scrolls horizontally in Firefox at least.

I think it's a configuration option when embedding the map, so it varies from site to site.

I believe you're correct, although I'm talking less about embedded maps, where I agree that having the map take over scrolling is aggravating, and more about the map interface in general.

No, I too want to use the trackpad to pan the map. Not least because my initial muscle memory is always "swipe to scroll" followed by "FECK GOOGLE" when it doesn't work and then switching to click-drag mode.

> Having the scroll wheel move in y with no scroll to move in x just seems...weird.

Scroll wheels are still a thing in 2019 ? I can scroll in any direction using either the trackpad or a Magic Mouse in pretty much every app and website except Google Maps.

I think the counter-argument is you can drag-and-drop to pan the map (a Google Maps innovation) and so scroll-wheel was used with a mouse to zoom in (a “wow” feature from back then). But this is all very 2005, mouse-centric. It makes more sense when you consider Google Maps went full screen in a redesign — which lets them behave more like a game or interactive experience than a webpage. I remember mapping scroll wheel to switch weapons in more than one game—scrolling in games isn’t something you expect to do with a scroll wheel. That said I get frustrated easily on mobile when I zoom in or out in a map and I don’t mean to. It’d be nice to have a little “Undo” button/bar appear for 10 sec just to make life a bit easier.

Actually 2016: https://cloud.google.com/blog/products/maps-platform/smart-s...

I actually only really hate this because now it requires two active hands to control the map element. I'm sure google already did consider this when they decided to change the functionality

Do you have a suggested alternative? Personally I love scroll to zoom on maps, find it a really natural action.

In many other apps (e.g., web browsers, Office apps) Control+Wheel is used for zoom. Any modifier key with the wheel would be fine.

What would the wheel do otherwise? I don't want the scroll wheel to pan vertically. I guess doing nothing is acceptable, but I honestly zoom enough that I actually prefer the one handed action on my computer. I probably would just go back to double clicking if scrolling to zoom required a modifier, and that's worse UX because there's all sorts of stuff I could accidentally click on when double clicking to zoom.

If they do choose to go with a modifier, I hope it's not control, because I hate accidentally zooming the page with the browser's zoom since it breaks nearly every page out there.

But this would compete with the browser zoom

Ugh, terrible UX. No, makes no sense. Users expect to use maps with scroll to zoom.

If you are going to have a Google Map on a contact us page it is better to not bother.

A static map may be underwhelming for the tech people but it is better. No need to load the Google plugin so +3s page load, so better search. Plus, if someone wants the map the link around the image can take them to Google Maps and they can then type in directions, see your reviews and bring actual business your way.

Cutting down the bloat helps, sometimes simpler is better.

At the moment I have a project where I am trimming the maps out of the footer of the home page.

The static maps I am putting in place have been saved with srcset images so the pin is in the middle with mobile and off to one side with desktop. mod_pagespeed does the image resizing so that the images a customer sees are always bandwidth friendly. Why have 3s of download (or more) when you can have a 12k image come down the same http2 connection?

Ah, yes, I had to spend an afternoon disabling that in 2011.

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?

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

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"?

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

Maybe if you have a scroll wheel, but with a Magic Mouse you can swipe in all directions and you would want it to pan around the map, not zoom.

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.

Unfortunately that's pretty much the only way not to confuse the majority of your users. It depends a bit on your target audience of course.

At work we have a lot of embedded Google Maps and any content below the map was rarely viewed. Once we disabled auto focus, we saw more and people scrolling to content below the embedded map. Suggesting that people got confused by it and simply left the page. For us, it was the right thing to do.

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.

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.

Scroll wheel is used to zoom in a number of applications, and I find it to be very useful.

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.

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

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

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.

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

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.

What happens when you convert 00000456 to an integer? Strings are safer, which is more important than space.

An IP address is actually a number that math may be performed upon.

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

...or any touch-pad or touch-mouse? Or really any device that scrolls?

I have never accidentally scrolled with either a touchpad or a normal mouse.

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

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

I created an html file with only a

    <input type="number">

element in it.

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

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.

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

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

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.

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]

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

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

And if there's only 10 or so reasonable/acceptable options, it should probably just be a menu instead.

What led you to that general rule?

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.

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

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.

OP probably doesn't need those stupid circle graphics that make reading the article title impossible to read.

https://imgur.com/a/QHtfBKn

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.

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.

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

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

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

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

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

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

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

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.

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.

You can specify the pattern attribute to be only numeric digits with "\d" .

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!

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

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?

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 and here's a 5 year old Stack Overflow answer about it: https://stackoverflow.com/a/14810932/597260

Thanks for sharing.

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.

"Thanks, Brad!"

Reply on news.ycombinator.com