Category: programming

I recently shared a post on hacker news about the app I’ve been building (keenforms). It actually sparked a lively discussion, although the most heated issue was not really about my product. It was about the <input type=”number”>, or rather the fact that we’re not using it.

At some point early on I tried using the number input in the form rendering page, but I ran into so many problems that it was just easier and more predictable to avoid it completely. We just use the <input type=”text”> for number data types, and use javascript to validate the value.

*Please note that we actually do use <input type=”number”> inside our app. However we only use it in the dashboard, for fields form attribute files such as position and score multiplier, because those validations are unconditional.

I discovered a lot of odd behavior when you use <input type=”number”>, but it never occurred to me to share all the problems I ran into. That is, until the hacker news post comments.

The pro number input crowd was primarily focused on the accessibility argument. The number input has the native increment/decrement buttons. It has built in validation as well. Some mobile devices will show a number keypad instead of the full keyboard.

There were also some complaints about developers overusing Javascript (guilty!). Keenforms relies heavily on javascript and specifically React, and Javascript is critical to the dynamic interactions that can be created using our software. I understand some people’s aversion to JavaScript. However JavaScript is the only way to create a decent user experience with real time responses for the forms that Keenforms was built for. There is no other way to provide the kind of real time dynamic feedback I wanted for Keenforms without JavaScript. If you want a form builder that will render properly for users who have disabled JavaScript, then you shouldn’t use Keenforms.

However I was not alone in the anti-number input camp. One user posted an article issued by the UK Government detailing all the problems related to the number input.

https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/

The mind blowing thing about this article is;

• The article didn’t mention the biggest problems I personally experienced AND
• The article mentioned a lot of problems I wasn’t even aware of until I read it, such as;
  • It cannot be dictated or selected when using Dragon Naturally Speaking
  • Certain browsers will round off large numbers
  • Scrolling with scroll wheel on the mouse

  At one point I stated that the number input was more trouble than it’s worth, and I could write an article why the number input was quantifiably terrible. The response I got was actually great;

  “please do write an article. Although I’m skeptical, I would read it with an open mind + in good faith.”

  So here is a short list of all the reasons the number input is terrible.

  The number input allows for invalid number values

  

  This by itself, while undesirable, is not the biggest issue, but it’s required information to understand the next problem.

  When the number input contains an invalid number value, and you retrieve the value via JavaScript you will get a BLANK STRING, (not actual contents displayed)

  

  There are a couple of ways you might go about retrieving the value. Could be on an event listener, which would mean event.target.value. Or through the DOM element. Either way you can’t get the value that’s actually in the <input type=”number”>

  const numberInput = document.getElementById('id_here');
  console.log(numberInput.value); // will return empty string if invalid

  The inability to see what the text input actually contains is a massive problem. It makes client side validation using Javascript impossible.

  

  While validation of form inputs on the back end is a must, client side form validation via Javascript is a critical tool to be able to provide better UX. If you’re just making sure the number is a number you might be ok with the built in number validation. However the reason I built my own form builder is that I wanted something better than that. As a programmer I routinely get requests to build forms with complex and conditional validations. Getting a blank string for an invalid number value is a deal breaker.

  It’s WAY TOO EASY to enter invalid number values into the number input

  The accepted characters when typing in the number input varies from browser to browser. Let’s start with the best case scenarios,

  Chrome and (surpise!) Microsoft Edge;

  The following characters are permitted (based on my hastily done first hand testing)

  • numbers 0-9
  • decimal point
  • “-” (minus for negative values)
  • “+” (plus because ¯\_(ツ)_/¯ ​​)
  • the letter ‘e’ – for exponential notation

  Both of these browsers will prevent you from entering the accepted non-numeric characters more than once. You can however place those symbols anywhere in the input, i.e. putting the minus symbol in between digits, which of course would make the number invalid.

  For browsers Firefox and Safari;

  There are no limits whatsoever, you can type whatever you want.

  All of these browsers will show a built-in popup to indicate that the value you’ve entered is not a valid number, and the submit button will not work without the user fixing those input values to be valid. The built in validation though is visually inconsistent when you are building dynamic responsive apps.

  The letter ‘e’ thing is annoying. The value 2.3e4, represents 2.3 times 10 to the power of 4, aka 23,000. Under most circumstances you don’t want exponential notation. If you enter a number big enough the number input will automatically convert your number to this format. For numbers that big it would seem HTML forms are not the best way to handle it, but that’s not my business. If you don’t know this already you should never use a number input for things like credit cards or phone numbers.

  Lastly there is one more stumbling block with the number input.

  Number input attributes like min and max help keep the value within range when typing or pressing native increment/decrement buttons. However out of range numbers can be copied/pasted into the input.

  The ability to set the minimum and maximum number values in the number input is a nice to have feature. The increment/decrement buttons will keep the number value within these range parameters. However you can copy/paste a value that is beyond those limits.

  If you are reading this last issue and saying this seems petty, I want you to know I totally agree with you. However it’s not always my call.

  Imagine a software tester finding this issue and logging a bug. Imagine the client product manager hearing about the bug. Imagine discussing this during sprint planning, but then pleading your case to that said product manager “this is an edge case and the number will be validated on the back end”. And besides, you said this was MVP and this “bug” is actually standard behavior of the number input. Imagine losing that battle and having to fix it anyway. All I’m saying is it’s not always the developers choice. Hypothetically of course.

  I suspect there’s stuff I don’t even know about. If you know another issue with the number input not cited here or the UK article we’d love to hear about it. I hope you learned something. Thanks for listening. And thanks to folkhack for prodding me into writing this article.