In summary the main issue is that, according to the spec, `<input type="number">` is only for numbers that are going to be parsed into a Javascript number. It has to make sense to increment, decrement or do other numerical operations on it. It's not to be used for strings or identifiers that just so happen to be numbers, e.g. credit card numbers. I'll admit this is slightly surprising to me but it does make a certain amount of sense.<p>The solution is to use `<input type=”text” inputmode=”numeric” pattern="[0-9]*">`.
This is off-topic, but I <i>really</i> like the current GOV.UK (several years old now). I don't really have opinions on the visual stuff, but I find it really pleasant to use.<p>Filing my self-assessment tax return (only required because I run a side-business) is a fantastically straightforward experience. Step-by-step information entry, pre-filled with what they already know (e.g. main employer's salary), then they give you a number at the end which you pay by card.<p>Having done the paper version exactly once before moving over to doing them online, I feel grateful every time I see that distinctive custom font.
Similarly, here is your reminder than US Zip Codes aren't numbers, because many of us here in the Northeast have them start with a zero (or even two). So don't store them as integers, because Boston is 02108, not 2108.<p>See <a href="https://en.wikipedia.org/wiki/List_of_ZIP_Code_prefixes" rel="nofollow">https://en.wikipedia.org/wiki/List_of_ZIP_Code_prefixes</a>
It's good to see UX design problems analyzed from a technical perspective. Designers working on the web should be proficient at understanding the medium on which they work, and look beyond generating static images to toss over the wall for implementation.
> However the inputmode attribute is now supported by all the mobile browsers we test in.<p>This isn't extensive, which might be a tad misleading if you don't double check. They test on Chrome & Samsung for Android, and iOS is only the one engine.<p>And those three browsers seem to be the only mobile browsers that have implemented it. (Well, Opera Mobile as well). [0]<p>Desktop support is also extremely spotty.<p>This seems like it might be leaping the gun on expecting this standard to pick up the slack.<p>Whilst they might feel the support is there for their particular audience after 2019, I wouldn't, and would suggest that you need to check your particular audience closely before following this advice for your own site. (Which is fairly generic advice, but appropriate.)<p>[0] <a href="https://caniuse.com/#feat=input-inputmode" rel="nofollow">https://caniuse.com/#feat=input-inputmode</a>
Using "numeric" types for strings that look like base 10 numbers is an incredibly common mistake. It's one of those mistakes that works 99% of the time, which means it can become deeply embedded in architectures. We've recently seen this problem when a database for the first time for a non-numeric system in its ids and downstream systems that converted that to an integer started to fail.<p>My rule of thumb is that if it doesn't make sense to do arithmetic on it then it's not a number, it's probably a string.
The Government Digital Service does all kinds of cool work around accessibility for both users using assistive technology and users who are less technically able. Interesting talk here from 2014 <a href="https://www.youtube.com/watch?v=CUkMCQR4TpY" rel="nofollow">https://www.youtube.com/watch?v=CUkMCQR4TpY</a>
This is another reminder that floating point numbers are just a hack that should never be used by default. We have enough CPU, memory and bandwidth that we are able to transmit/store exact representation of numeric user input, and convert it to float only when necessary, as designed by programmer.
<input type=number> for things that are like telephone numbers and not like quantities is such a common mistake. It can be hilarious when, for example, a login form uses such a field for a Swedish personal identity number. I just need to click the up arrow ~1.996×10¹¹ times!
Really interesting article, and as with everyone else I also really admire their commitment to accessible design.<p>One interesting this I noticed in this piece was the text (not quoted for reasons that will soon become clear):<p>Using <input type=”text” inputmode=”numeric” pattern="[0-9]*"> allows for a degree of separation between how the user enters data (“input mode”), what the browser expects the user input to contain (type equals number), and potentially how it tries to validate it.<p>Which has incorrectly used closing quotes and correctly used straight quotes in the same code section, and then proper opening and closing quotes in the text section. I wonder how that happened.
Javascript not having proper integers strikes again! Kind of surprised they hadn't run into more issues parsing string-ids-with-numerals into numbers.
Does anyone know what's going on with the Firefox implementation of inputmode, especially for Android? There isn't much on Bugzilla about it.
I'm no web-dev, but shouldn't these things be sanitized server-side? In which case, except for the mobile keypad issue, all these problems would solve themselves?<p>And shouldn't they be doing this anyway?