Hacker News Reader

Comment by idbehold | Hacker News Reader

She didn't even touch upon the crazy <input type="number"> which will allow the user to enter in non-number input such as a dollar signs and letters. However, when you try to access said input's value from the DOM it will give you back an empty string since what the user entered (and what is still displayed to the user) isn't a valid "number". Great!

In this case the input won't even fire a change event because before the user entered anything the value was "" and after the user entered the invalid input the value (according to the DOM) is still "". No change!

View on HN

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

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.

I thought using email+tag is quite common nowadays to auto-sort the letters, and the site which doesn't support it is absolutely breaking the email experience.

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.

> Everyone ignores it and tries to reinvent their own idea of what the standard could be.

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.

Addresses don’t need @ signs to be valid, though…

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.

<input type="number"> is just completely awful. To handle it properly in our React application, we have a <NumberInput> component which is roughly 200 lines (and shrinking, thankfully), involving more than a few browser-specific validity checks and keydown handlers.

The only way to keep non-numbers out of your number input is to cancel keydown events selectively, but it's still a crapshoot. And I've been bitten a few times by that bizarre change issue you mentioned.

If there's not already a good MIT-licensed project that encapsulates inputs and gets the weird out, I think it would be worth doing, whether in React or Web Components or both.

> The only way to keep non-numbers out of your number input is to cancel keydown events selectively

There's a much simpler way: monitor the "input" event, and whenever fired, do this.value = this.value.replace(/\D/g,'');

The user will never see anything they type other than numbers.

This will blow away the cursor position:

  User enters:    `1245|`
  Navigates back: `12|45`
  Enters 'a3':    `12453|`
  Instead of:     `12345`

There are a ton of "gotchas" in this. Pretty frustrating.

The user's cursor will also be moved to the end of the inputted text with every keystroke.

I don't believe that will work since the input.value will become an empty string before you can do your replacement.

I think you would use a text input if you were writing your own component with better number behavior

You'll trigger the wrong on-screen keyboard on mobile devices. There was talk about an inputmode attribute where you could specify "numeric" to instruct the OS to present the appropriate keyboard to the user without changing the input's behavior, but it isn't supported anywhere AFAIK.

Any plans on open sourcing yours?

Who comes up with this stuff? I've used the MS GUI toolkits (WinForms, WPF, Web Forms if you consider that similar) and don't recall ever hearing about such obviously poorly designed stuff. They aren't perfect but they're fairly great. I've heard OK this about other GUI kits, too. What attracts such terrible stuff to the web?

> I've used the MS GUI toolkits (WinForms, WPF, Web Forms if you consider that similar) and don't recall ever hearing about such obviously poorly designed stuff.

The raw Win32 API is worse than the Web APIs.

but the Win32 api also comes from what, 1993? Number input type is quite a bit more recent, we might expect something better.

Actually, 1985. Windows 1.0 had the exact set of APIs which later expanded to 32-bit and subsequently 64-bit.

Having worked with WinAPI for some time no, it's not worse than Web APIs. It seems to be more well thought-through, which probably says more about the current state of the web.

I couldn't disagree more, having worked with both sets of APIs. The Web APIs have benefited from a long period of multi-vendor standardization and consensus, something the Windows API has never had.

You know what they say about making chicken salad?

Windows might not be top-brand chicken, but it's at least poultry.

Design by committee.

In many cases, the bad APIs were actually the opposite: "design by some random person at Netscape in the 90s".

Read the history of the <blink> tag if you want a example : http://www.montulli.org/theoriginofthe%3Cblink%3Etag

So it literally was invented after a night of drinking at a bar. :-) I wonder about the origins of <marquee>.

MARQUEE started out as a "feature" of very early versions of Internet Explorer, as a way for IE to differentiate itself from Netscape. (Don't hate Microsoft too much for this -- they were just following the lead of Netscape, who had their own proprietary tags. Heck, IMG started out as a Netscape-only tag.)

There was a real danger for a few years in the mid-'90s that competition between browsers would manifest itself in a proliferation of proprietary tags that only worked with one browser or another. The old "Best viewed with..." buttons that sites used to festoon themselves with (examples: http://cjihrig.com/blog/wp-content/uploads/2011/12/best_view...) were an artifact of this; they advertised that a site used one browser or another's particular set of proprietary tags, which was how you positioned yourself as "cutting edge" in, say, 1996.

Things are better now, thankfully. (Not much better, but better.)

"WhatsApp Web requires Chrome or Opera"

"Google Inboxbeta only works in Chrome"

I’d say things are just as bad as before

True, but that's because whatever site can choose to rely on a cutting edge specced feature that the other browsers haven't implemented yet. At least it's not the 4 different companies trying to one-up each other.

But that’s what previous browser wars also were about: one browser implements experimental technology, all websites target it, etc.

Chrome has become the new IE in the meaning that it supports weird special stuff, but sometimes not the official W3C definition, and webapps rarely work on multiple browsers.

The IMG tag showed up before there was a Netscape.

You know that venture giant, the 'A' in A16Z? Long time ago he was marca without the initial 'p', maintained an emacs clone called Epoch, and also hacked away on a web browser called Mosaic:

http://1997.webhistory.org/www.lists/www-talk.1993q1/0182.ht...

You're right, of course, I was mentally mixing up Mosaic with Netscape. I blame old age.

Probably cocaine.

> I wonder about the origins of <marquee>

Probably invented by some lunatic.

Oh yeah, this bit me in a widget I made for a client. But it only bit me once I tried it in Chrome, IIRC. Browser inconsistency, yay :/

I just used an <input type=text> and checked its content upon keydown instead.

Interesting. So is there some quick and easy JS plugin that will auto validate number fields correctly? For instance, I have <input type="number" step="0.25" min="1" max="99">

If I input an invalid entry in Firefox (say 101, or 25.11), FF will highlight the box red. In Chrome it does nothing. Both allow me to submit that data just fine.

Reply on news.ycombinator.com