Hacker News Reader

Comment by benatkin | Hacker News Reader

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.

View on HN

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.

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.

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.

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

Reply on news.ycombinator.com