3 ms·

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

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
      The edge case I cited and your solution works. This method will help make the distinction between a non required number input containing an invalid value versus blank. I learned something today. Thank you for this. I'm going to read more about the constraint validation API. I stand by my criticism of the fact that the DOM API does not give you the value that appears in the number input. It's actually infuriating. Also your solution does not solve the problem of a stake holder or product manager or designer who is unhappy about the visual inconsistencies across different browsers and the different validations. Yes the built in validation is useful. However for many of the clients I work for they have high expectations and different demands. The solution you're providing might meet the technical requirement of treating blank like a zero but it would not be accepted by the clients I deal with. The built in browser validation takes precedence over the javascript validation that is custom built. This has become a massive problem. Even with the ability to customize the error message that doesn't mean the people who are designing or paying for whatever I'm building will find it acceptable. I haven't tested it but I'd be curious what would happen with a large form and multiple native errors, and how do you direct the user to go to each of the inputs that have errors. I'm not going to list every possible use case, but I've seen a lot. Once you cross a threshold of complexity with javascript form validation the native validation becomes a hinderance that is hard to overcome. I know there are people on this forum with opinions without having the level of expertise that merits making comments. Not reading someone else's comment while being insulting doesn't help either. And as far as I'm concerned avoiding using the number input is the least worst option for many of the projects I'm involved with. I could expound upon the input.valueAsNumber method in an update of the article, that's useful in a certain but not all cases. I stand by the content of the article and based on the clients I serve I plan to continue to avoid using the number input. The invalid value as blank string is a deal breaker.

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
    The edge case I cited and your solution works. This method will help make the distinction between a non required number input containing an invalid value versus blank. I learned something today. Thank you for this. I'm going to read more about the constraint validation API. I stand by my criticism of the fact that the DOM API does not give you the value that appears in the number input. It's actually infuriating. Also your solution does not solve the problem of a stake holder or product manager or designer who is unhappy about the visual inconsistencies across different browsers and the different validations. Yes the built in validation is useful. However for many of the clients I work for they have high expectations and different demands. The solution you're providing might meet the technical requirement of treating blank like a zero but it would not be accepted by the clients I deal with. The built in browser validation takes precedence over the javascript validation that is custom built. This has become a massive problem. Even with the ability to customize the error message that doesn't mean the people who are designing or paying for whatever I'm building will find it acceptable. I haven't tested it but I'd be curious what would happen with a large form and multiple native errors, and how do you direct the user to go to each of the inputs that have errors. I'm not going to list every possible use case, but I've seen a lot. Once you cross a threshold of complexity with javascript form validation the native validation becomes a hinderance that is hard to overcome. I know there are people on this forum with opinions without having the level of expertise that merits making comments. Not reading someone else's comment while being insulting doesn't help either. And as far as I'm concerned avoiding using the number input is the least worst option for many of the projects I'm involved with. I could expound upon the input.valueAsNumber method in an update of the article, that's useful in a certain but not all cases. I stand by the content of the article and based on the clients I serve I plan to continue to avoid using the number input. The invalid value as blank string is a deal breaker.