So here is a short list of all the reasons the number input is terrible.<\/span><\/p>\nThe number input allows for invalid number values<\/h3>\n
<\/p>\n
This by itself, while undesirable, is not the biggest issue, but it’s required information to understand the next problem.<\/p>\n
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)<\/h3>\n
<\/p>\n
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”><\/p>\n
const numberInput = document.getElementById('id_here');\r\nconsole.log(numberInput.value); \/\/ will return empty string if invalid<\/pre>\nThe inability to see what the text input actually contains is a massive problem. It makes client side validation using Javascript impossible.<\/span><\/p>\n<\/p>\n
While validation of form inputs on the back end is a must, client side form validation via Javascript<\/span> 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.<\/p>\nIt\u2019s WAY TOO EASY to enter invalid number values into the number input<\/b><\/h3>\n
The accepted characters when typing in the number input varies from browser to browser. Let\u2019s start with the best case scenarios, <\/span><\/p>\nChrome and (surpise!) Microsoft Edge;<\/b><\/p>\n
The following characters are permitted (based on my hastily done first hand testing)<\/span><\/p>\n\n- numbers 0-9<\/span><\/li>\n
- decimal point<\/span><\/li>\n
- \u201c-\u201d (minus for negative values)<\/span><\/li>\n
- \u201c+\u201d (plus because <\/span>\u00af\\_(\u30c4)_\/\u00af <\/span>\u200b\u200b)<\/span><\/li>\n
- the letter \u2018e\u2019 – for exponential notation<\/span><\/li>\n<\/ul>\n
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.<\/span><\/p>\nFor browsers Firefox and Safari;<\/b><\/p>\n
There are no limits whatsoever, you can type whatever you want.<\/span><\/p>\nAll of these browsers will show a built-in popup to indicate that the value you\u2019ve 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.<\/span><\/p>\nThe letter \u2018e\u2019 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\u2019t 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.<\/span><\/p>\nLastly there is one more stumbling block with the number input.<\/p>\n
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.<\/h2>\n
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.<\/p>\n
If you are reading this last issue and saying this seems petty, I want you to know I totally agree with you. However it\u2019s not always my call.<\/span><\/p>\nImagine 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 \u201cthis is an edge case and the number will be validated on the back end\u201d. And besides, you said this was MVP and this \u201cbug\u201d is actually standard behavior of the number input. Imagine losing that battle and having to fix it anyway. All I\u2019m saying is it\u2019s not always the developers choice. Hypothetically of course.<\/span><\/p>\nI 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<\/a> for prodding me into writing this article.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"I recently shared a post on hacker news about the app I\u2019ve 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=\u201dnumber\u201d>, or rather the fact that we\u2019re not using it. At some point early on I tried using […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[9,10],"tags":[11],"class_list":["post-130","post","type-post","status-publish","format-standard","hentry","category-javascript","category-programming","tag-javascript"],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/blog.keenforms.com\/blog\/wp-json\/wp\/v2\/posts\/130","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.keenforms.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.keenforms.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.keenforms.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.keenforms.com\/blog\/wp-json\/wp\/v2\/comments?post=130"}],"version-history":[{"count":10,"href":"https:\/\/blog.keenforms.com\/blog\/wp-json\/wp\/v2\/posts\/130\/revisions"}],"predecessor-version":[{"id":144,"href":"https:\/\/blog.keenforms.com\/blog\/wp-json\/wp\/v2\/posts\/130\/revisions\/144"}],"wp:attachment":[{"href":"https:\/\/blog.keenforms.com\/blog\/wp-json\/wp\/v2\/media?parent=130"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.keenforms.com\/blog\/wp-json\/wp\/v2\/categories?post=130"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.keenforms.com\/blog\/wp-json\/wp\/v2\/tags?post=130"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}