Item — HN Reader

Number inputs are amazingly bad. In many languages, comma is considered the correct decimal separator [1], but if your users enter that they will break the input in about half of the browsers.

As far as I understand, there's no way to feature detect this stuff. Why not just use text input? Because on iOS, `type="number"` is the only way to get a keyboard with both digits and a decimal separator. So, browser sniffing it is...

[1] http://www.statisticalconsultants.co.nz/blog/how-the-world-s...

5 comments

The mobile on-screen keyboards are the only reason I even attempted to use <input type="number">. I could've gotten away with using <input type="tel"> which doesn't have any type of validation associated with it, but the keyboard presented on iOS doesn't have a period key (or a comma for those other languages) which means you can only enter natural numbers. Android on the other hand does provide a way to enter periods form the "tel" on-screen keyboard.

What I don't understand is why this weird validation behavior only exists for <input type="number"> and not for other input types that have built-in validation rules such as <input type="email"> and <input type="url">. Imagine an <input type="email"> reporting that its value is an empty string if the user didn't enter a completely valid email address.

I actually had that exact problem, when writing an app with Ionic. It looks like a "feature" of Angular, as can be seen on their documentation [1].

[1] https://docs.angularjs.org/api/ng/input/input%5Bemail%5D

You can still get the actual value from DOM even if Angular is updating your model with an empty string.

Well the definition of a valid email address is very hard to get right and it can conceivably change.

The email address format is very well defined in rfc822. What do you mean by "it can change"?

RFC 822 is so loose in what it accepts compared to conventional use that it doesn't help with validation to prevent input mistakes, though it's effectively a lost cause. Since someone could theoretically have the address:

"<blink> !_joe!jim%foo_jay\@sus/\$ch=rist;`rm -fr /`"@example.com

Perfectly fine according to RFC 822.

RFC 2822 is better and rejects that, so things have changed for the better, and theoretically could change again (though I wouldn't bet money on it).

RFC 2822 still accepts:

"joe!jim%foo_jaysus/cee=rist;`rm -fr /`"@example.com

We must accept there's no reliable and correct way to help with many classes of actual user errors on input even if the world's existing SMTP servers can actually choke on valid RFC 822/RFC 2822 addresses.

I don't see what's wrong with: "joe!jim%foo_jaysus/cee=rist;`rm -fr /`"@example.com

This is what the user says their email is. If their mail server accepts it, what's the problem? I'd rather like the original 822 to be accepted, than "simple_email@example.com" be rejected because "OMG you can't have `_` in your address!". It just leads to validation of what the developer think is kosher, rather than what will work.

This extends to so many other things: email, post code, phone number, names, ... It's terrible when developers think they know those details better than the user does.

While there's nothing "wrong" with it in the sense of following the standard, it's nice to be able to help people spot mistakes when entering things.

With email I warn on weird input, but accept provided it's compliant since the goal is to help - the miniscule fraction of people with email addresses who have really peculiar addresses are far fewer than those who make typos when entering them. '_' isn't really peculiar, though.

> help people spot mistakes when entering things

I completely agree. Here's how it should work: "your email abc+def@example.com is valid but looks unusual, are you sure it's your email? ok/cancel". Not: "your email is invalid, guess which of our made up rules it violates". But you're in a tiny minority of people who handle this properly.

Except like 95% of the sites out there won't accept that e-mail, and I'm betting 50+% of mail servers will choke on it too, because developers love their regexes.

RFC822 allows you to even put comments in your e-mail. joe(Hello, Hacker News! How are we doing today?)doe@example.com is a valid e-mail as well (AFAIR; it's been a few years since I had to read that and related specs and implement something according to them).

> Except like 95% of the sites out there won't accept that e-mail

And that's the problem. There's a standard. Everyone ignores it and tries to reinvent their own idea of what the standard could be. It only leads to issues. If people think that the standard is so bad, they're of course welcome to produce and post their own RFC for discussion. But making up their own version of rules is bad and pretending there is no existing standard is also bad.

I tested "`rm -fr /`"@mydomain.com with Gmail and it works. Thanks for my new email address :D

Edit: I also signed up for Twitter with that address and the confirmation mail was delivered.

Just because someone made an rfc, doesn't mean that the rfc is the de facto standard.

RFCs are closer to de jure standards, even if they aren't forced by law.

Exactly. And de jure doesn't make something de facto automatically.

As long as the RFC is marked as such, that's exactly what it means.

You're confused about de facto vs. de jure. It's a common thing to be ignorant about, but maybe in the future don't be all "No, no, you're exactly wrong!" before double-checking.

Though, if it's so often misunderstand perhaps I should be calling it `on paper' vs `in practice'.

Adding novalidate to the form tag stops the in-built validation madness, but still gives the relevant keyboard on mobile browsers.

Not sure how I've missed this for so long, thank you.

> Why not just use text input? Because on iOS, `type="number"` is the only way to show the number keyboard

Actually, this isn't true. It will also show the number keyboard on a normal type=text input if you add a pattern="[0-9]*" property.

EDIT: Sorry, misread your comment; you wanted the decimal separator too. I believe that might be impossible to get without type=number.

> Why not just use text input? Because on iOS, `type="number"` is the only way to get a keyboard with both digits and a decimal separator.

Really? How would you enter a street address into a form consisting of just text inputs?

It's the only way to default to the number keys when the keyboard comes up. The user can of course switch to it manually in a regular text input.

There's a way to detect the system decimal separator using JavaScript, but it only works in IE and Firefox, and it doesn't work in Chrome because it is marked as 'optional' in the standard.