6 ms·
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 doe
by idbehold 11y ago
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.
- joshuahutt 11y agoI 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 https://docs.angularjs.org/api/ng/input/input%5Bemail%5D
- idbehold 11y agoYou can still get the actual value from DOM even if Angular is updating your model with an empty string.
- hueving 11y agoWell the definition of a valid email address is very hard to get right and it can conceivably change.
- viraptor 11y agoThe email address format is very well defined in rfc822. What do you mean by "it can change"?
- eru 11y agoJust because someone made an rfc, doesn't mean that the rfc is the de facto standard.
- lokedhs 11y agoAs long as the RFC is marked as such, that's exactly what it means.
- jfarmer 11y agoYou'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.
- eru 11y agoThough, if it's so often misunderstand perhaps I should be calling it `on paper' vs `in practice'.
- nitrogen 11y agoRFCs are closer to de jure standards, even if they aren't forced by law.
- eru 11y agoExactly. And de jure doesn't make something de facto automatically.
- nemo 11y agoRFC 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.