4 ms·

> I won’t pretend to be the expert on all things related to forms Indeed. All of the issues the author is experiencing can be easily fixed with simple and read

> I won’t pretend to be the expert on all things related to forms Indeed. All of the issues the author is experiencing can be easily fixed with simple and readily documented javascript methods: > When the number input contains an invalid value and you retrieve the value, you get a blank string > Valid numbers include more than just digits (i.e,. scientific notation like the letter e). > Different browsers accept different characters Use inputElement.valueAsNumber and stop worrying. If you send the form unaltered (that is, without intercepting the submit event), use a custom validator. https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputElement/setCustomValidity https://developer.mozilla.org/en-US/docs/Web/API/HTMLInputEl... > Min/max limits can be bypassed Use frontend validation, e.g. inputElement.validity https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Constraint_validation https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Cons... There are plenty of weird form elements out there, but input type=number is actually one of the better one. But the author is definitely very right about one thing: > You should only use the number input when dealing with mathematically relevant numeric values Mathematically relevant might be to strict. I would say that if ordering the numbers makes sense, then input type=number most likely makes sense as well. If your data is simply represented by a number (e.g. zip codes; 90210 < 98112 is a weird statement) input type=number is the wrong choice.

padseeker 4y ago
There have been requests for functionality to use an inputs value for a calculation, like for a price estimate. The requirements were also for a blank input to be treated as a zero. Because of the invalid value returned as blank there is no way to make the distinction between an invalid value and a blank value. The valueAsNumber will return NaN for a blank value or invalid. The fact that the DOM API returns a blank value for an invalid number is a massive misstep on the part of whoever makes the decisions surrounding the DOM API. The W3C? Whatever, this is a truly awful decision. I don't know pretend to be the expert. But I've seen a lot of things, and I've learned a lot over the past 15 years. For certain requirements there is no way to clear this problem.
- runarberg 4y ago
  Seems pretty clear cut for me: const value = input.value ? input.valueAsNumber : 0; Or if you want to be super defensive: const value = Number.isNaN(input.valueAsNumber) ? 0 : input.valueAsNumber; The nice thing is that constraint validation will not validate empty inputs unless you put the required attribute on the input. However if it were me, I would default the input field to 0 (as in <input type=number value=0>) so that most users wouldn’t be confused by an unexpected default behavior.
  - padseeker 4y ago
    I can't make this any clearer to you - if you have an invalid value like "ABC" you don't want to treat it like a zero, you want to treat it like an invalid value and not perform the calculation until the user corrects the number. On the other hand if the input is blank you want to treat the value as a zero and perform the calculation. The problem of getting a blank string for an invalid value means you cannot make the distinction between the 2. I cannot make it any clearer than this. Not everyone wants to treat a blank number input as a zero, and the ideal situation would have been to default the number input to zero. However like I said in the article multiple times it's not always my call or decision. That why the native validation and visual inconsistency across browsers as well as non compliance with mockups is a problem I've encountered multiple times. When you you cannot see an invalid value or make the distinction between blank and invalid number you lose control over work flow. Also you rubbed me the wrong way with the snide "indeed" comment. Talking down to people is not a good way to generate a thoughtful debate. I try to approach these things with a certain level of humility. I don't know everything, I even learned a couple of things from other people when I published this article. Have you considered that maybe you don't know every possible requirement or request that I have?
    - runarberg 4y ago
      I see what your problem is (sorry I read too quickly). What you want to do is use the constraint validation API (https://developer.mozilla.org/en-US/docs/Web/API/Constraint_validation https://developer.mozilla.org/en-US/docs/Web/API/Constraint_...) let value = input.valueAsNumber; if (Number.isNaN(value) && input.validity.valid) { // or !input.validity.badInput if you want to be specific value = 0; } If the field is empty you’ll get 0, if it is an invalid number you’ll get NaN, if it is a valid number, you’ll get that number parsed according to the user’s locale. The current implementation does allow for variety of use cases, it does allow for developers to distinguish between an empty and an invalid value. (it does not allow developers to distinguish between different valid representation, but I consider that a feature as it accommodates for different user eccentricity and locales; as long as you intercept the submit event and use input.valueAsNumber). I’m sorry that I was insulting, but I’ve seen a lot of people on this forum with opinions about the state of front end development while not having any sort of expertise, and only rudimentary experience (as their expertise lies elsewhere). In your article you complain about front end feature that we front end developers use all the time (even you admit to using it), you complain that it is lacking, but you don’t even mention the techniques we use around those issues. There is no mention of input.valueAsNumber in your article, neither do you mention constraint validation API. Both are tools which allow us to deal with the issues you mention. Elsewhere in the thread there are people recommending that you simply don’t use <input type=number>, this is a horrible advice (you your self admit there are use cases for it). But this is what happens when you misrepresent the techniques that front end developers use to deal with issues in the platform (or, worse, don’t mention them at all).
padseeker 4y ago
And while we are on the subject it should be noted that number params submitted with exponential notation, i.e. 2.47e3 will not always be converted to a number. The app I built uses Ruby on Rails. While Ruby is smart enough to convert the scientific notation, the params are sanitized, so that everything up to and including the e is dropped, so 2.47e3 which represents 2,470 will be saved as 2. Every back end will handle things differently. On top of that the visual inconsistencies across browsers is a big issue. The native functionality of the number input will not be approved by most product managers and designers.
- runarberg 4y ago
  Most people I know actually intercept the submit event and convert the form to a JSON object before sending to the server. This is in fact the default behavior for most front end framework. If you do that then you can use input.valueAsNumber and it won’t matter how the user types the number as long as the browser understands it. Your product manager should be happy that their European users can type 13,37 while American users can type 13.37 and everyone is happy. The visual inconsistencies have been figured out a long time ago. I don’t think it would be easy for you to find a competent front end developer that is unable to style a number input according to—or close to—your designer’s spec. I’ll admit that styling validation errors is a bit involved, but if you are using the constraint validation API (as you should) you are doing that anyway regardless of the input type.

padseeker 4y ago

There have been requests for functionality to use an inputs value for a calculation, like for a price estimate. The requirements were also for a blank input to be treated as a zero. Because of the invalid value returned as blank there is no way to make the distinction between an invalid value and a blank value. The valueAsNumber will return NaN for a blank value or invalid. The fact that the DOM API returns a blank value for an invalid number is a massive misstep on the part of whoever makes the decisions surrounding the DOM API. The W3C? Whatever, this is a truly awful decision. I don't know pretend to be the expert. But I've seen a lot of things, and I've learned a lot over the past 15 years. For certain requirements there is no way to clear this problem.

runarberg 4y ago
Seems pretty clear cut for me: const value = input.value ? input.valueAsNumber : 0; Or if you want to be super defensive: const value = Number.isNaN(input.valueAsNumber) ? 0 : input.valueAsNumber; The nice thing is that constraint validation will not validate empty inputs unless you put the required attribute on the input. However if it were me, I would default the input field to 0 (as in <input type=number value=0>) so that most users wouldn’t be confused by an unexpected default behavior.
- padseeker 4y ago
  I can't make this any clearer to you - if you have an invalid value like "ABC" you don't want to treat it like a zero, you want to treat it like an invalid value and not perform the calculation until the user corrects the number. On the other hand if the input is blank you want to treat the value as a zero and perform the calculation. The problem of getting a blank string for an invalid value means you cannot make the distinction between the 2. I cannot make it any clearer than this. Not everyone wants to treat a blank number input as a zero, and the ideal situation would have been to default the number input to zero. However like I said in the article multiple times it's not always my call or decision. That why the native validation and visual inconsistency across browsers as well as non compliance with mockups is a problem I've encountered multiple times. When you you cannot see an invalid value or make the distinction between blank and invalid number you lose control over work flow. Also you rubbed me the wrong way with the snide "indeed" comment. Talking down to people is not a good way to generate a thoughtful debate. I try to approach these things with a certain level of humility. I don't know everything, I even learned a couple of things from other people when I published this article. Have you considered that maybe you don't know every possible requirement or request that I have?
  - runarberg 4y ago
    I see what your problem is (sorry I read too quickly). What you want to do is use the constraint validation API (https://developer.mozilla.org/en-US/docs/Web/API/Constraint_validation https://developer.mozilla.org/en-US/docs/Web/API/Constraint_...) let value = input.valueAsNumber; if (Number.isNaN(value) && input.validity.valid) { // or !input.validity.badInput if you want to be specific value = 0; } If the field is empty you’ll get 0, if it is an invalid number you’ll get NaN, if it is a valid number, you’ll get that number parsed according to the user’s locale. The current implementation does allow for variety of use cases, it does allow for developers to distinguish between an empty and an invalid value. (it does not allow developers to distinguish between different valid representation, but I consider that a feature as it accommodates for different user eccentricity and locales; as long as you intercept the submit event and use input.valueAsNumber). I’m sorry that I was insulting, but I’ve seen a lot of people on this forum with opinions about the state of front end development while not having any sort of expertise, and only rudimentary experience (as their expertise lies elsewhere). In your article you complain about front end feature that we front end developers use all the time (even you admit to using it), you complain that it is lacking, but you don’t even mention the techniques we use around those issues. There is no mention of input.valueAsNumber in your article, neither do you mention constraint validation API. Both are tools which allow us to deal with the issues you mention. Elsewhere in the thread there are people recommending that you simply don’t use <input type=number>, this is a horrible advice (you your self admit there are use cases for it). But this is what happens when you misrepresent the techniques that front end developers use to deal with issues in the platform (or, worse, don’t mention them at all).

padseeker 4y ago

And while we are on the subject it should be noted that number params submitted with exponential notation, i.e. 2.47e3 will not always be converted to a number. The app I built uses Ruby on Rails. While Ruby is smart enough to convert the scientific notation, the params are sanitized, so that everything up to and including the e is dropped, so 2.47e3 which represents 2,470 will be saved as 2. Every back end will handle things differently. On top of that the visual inconsistencies across browsers is a big issue. The native functionality of the number input will not be approved by most product managers and designers.

runarberg 4y ago
Most people I know actually intercept the submit event and convert the form to a JSON object before sending to the server. This is in fact the default behavior for most front end framework. If you do that then you can use input.valueAsNumber and it won’t matter how the user types the number as long as the browser understands it. Your product manager should be happy that their European users can type 13,37 while American users can type 13.37 and everyone is happy. The visual inconsistencies have been figured out a long time ago. I don’t think it would be easy for you to find a competent front end developer that is unable to style a number input according to—or close to—your designer’s spec. I’ll admit that styling validation errors is a bit involved, but if you are using the constraint validation API (as you should) you are doing that anyway regardless of the input type.