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...
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.
[1] https://docs.angularjs.org/api/ng/input/input%5Bemail%5D
"<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.
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.
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.
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.
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).
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.
Sure, but that's not a failing of developers, the standard just happens to be too complex to validate without language or module support. If JS had an isValidEmail() function everyone would use it and be consistent, but without one the options are to google up some massive (but still imperfect) regex, or accept any string with an @ sign in it somewhere, or choose some random point in between.
Edit: I also signed up for Twitter with that address and the confirmation mail was delivered.
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.
Really? How would you enter a street address into a form consisting of just text inputs?