8 ms·

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, w

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!

STRML 11y ago
<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.
- Keats 11y ago
  Any plans on open sourcing yours?
- nmjenkins 11y ago
  > 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.
  - idbehold 11y ago
    I don't believe that will work since the input.value will become an empty string before you can do your replacement.
    - eloisius 11y ago
      I think you would use a text input if you were writing your own component with better number behavior
      - idbehold 11y ago
        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.
  - MatmaRex 11y ago
    The user's cursor will also be moved to the end of the inputted text with every keystroke.
  - sgrove 11y ago
    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.
tobr 11y ago
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-separates-its-decimals.html http://www.statisticalconsultants.co.nz/blog/how-the-world-s...
- 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 ago
    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 https://docs.angularjs.org/api/ng/input/input%5Bemail%5D
    - idbehold 11y ago
      You can still get the actual value from DOM even if Angular is updating your model with an empty string.
  - hueving 11y ago
MichaelGG 11y ago
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?
- randallsquared 11y ago
  Design by committee.
  - pcwalton 11y ago
    In many cases, the bad APIs were actually the opposite: "design by some random person at Netscape in the 90s".
    - staz 11y ago
      Read the history of the <blink> tag if you want a example : http://www.montulli.org/theoriginofthe%3Cblink%3Etag http://www.montulli.org/theoriginofthe%3Cblink%3Etag
      - ssewell 11y ago
        So it literally was invented after a night of drinking at a bar. :-) I wonder about the origins of <marquee>.
        krapp 11y ago
        Probably cocaine.
        smacktoward 11y ago
        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_viewed_with_ie_or_netscape.jpg 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.)
TazeTSchnitzel 11y ago
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.
esaym 11y ago
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.

STRML 11y ago

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

Keats 11y ago
Any plans on open sourcing yours?
nmjenkins 11y ago
> 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.
- idbehold 11y ago
  I don't believe that will work since the input.value will become an empty string before you can do your replacement.
  - eloisius 11y ago
    I think you would use a text input if you were writing your own component with better number behavior
    - idbehold 11y ago
      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.
- MatmaRex 11y ago
  The user's cursor will also be moved to the end of the inputted text with every keystroke.
- sgrove 11y ago
  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.

tobr 11y ago

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-separates-its-decimals.html http://www.statisticalconsultants.co.nz/blog/how-the-world-s...

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 ago
  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 https://docs.angularjs.org/api/ng/input/input%5Bemail%5D
  - idbehold 11y ago
    You can still get the actual value from DOM even if Angular is updating your model with an empty string.
- hueving 11y ago

MichaelGG 11y ago

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?

randallsquared 11y ago
Design by committee.
- pcwalton 11y ago
  In many cases, the bad APIs were actually the opposite: "design by some random person at Netscape in the 90s".
  - staz 11y ago
    Read the history of the <blink> tag if you want a example : http://www.montulli.org/theoriginofthe%3Cblink%3Etag http://www.montulli.org/theoriginofthe%3Cblink%3Etag
    - ssewell 11y ago
      So it literally was invented after a night of drinking at a bar. :-) I wonder about the origins of <marquee>.
      - krapp 11y ago
        Probably cocaine.
      - smacktoward 11y ago
        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_viewed_with_ie_or_netscape.jpg 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.)

TazeTSchnitzel 11y ago

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.

esaym 11y ago

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.