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.

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.

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.

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

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

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

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

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]

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

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

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.

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?

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.

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.

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!

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?

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.

undefined

"Thanks, Brad!"

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.