4 ms·

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 valu

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
    > The built in browser validation takes precedence over the javascript validation that is custom built. What I do is I actually implement my custom validation with the constraint validation API (input.setCustomValidity()) and display the errors from there (using input.validationMessage). The custom validation actually takes president over other errors, if you don’t want that you can conditionally only set custom validity to a non-empty string when input.validity.valid === true. There is one annoying part about this method, it is that invalid form will prevent the submit event from firing. This means that you have to put novalidate attribute on your form and fire the validation manually (using form.checkValidity() during the submit event; don’t use form.reportValidity() unless you want the browser to impose on your UI design). Now you can do whatever you want during the submit event, including: a) preventing it if the form is invalid, b) displaying error messages however you want by manipulating the DOM, and c) move the focus to whichever invalid input element you want. I know this is involved, but it isn’t hard for a front end developer that knows what they are doing. The point is that a front end developer knows how to work with the platform (not against it) by using the same APIs as the platform does. In the case of <input type=number> that API is the constraint validation API. If you don’t use it, but still want custom behavior, you are going to have a bad time, and that is not the platform’s fault (and certainly not the fault of any one element in it).

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
  > The built in browser validation takes precedence over the javascript validation that is custom built. What I do is I actually implement my custom validation with the constraint validation API (input.setCustomValidity()) and display the errors from there (using input.validationMessage). The custom validation actually takes president over other errors, if you don’t want that you can conditionally only set custom validity to a non-empty string when input.validity.valid === true. There is one annoying part about this method, it is that invalid form will prevent the submit event from firing. This means that you have to put novalidate attribute on your form and fire the validation manually (using form.checkValidity() during the submit event; don’t use form.reportValidity() unless you want the browser to impose on your UI design). Now you can do whatever you want during the submit event, including: a) preventing it if the form is invalid, b) displaying error messages however you want by manipulating the DOM, and c) move the focus to whichever invalid input element you want. I know this is involved, but it isn’t hard for a front end developer that knows what they are doing. The point is that a front end developer knows how to work with the platform (not against it) by using the same APIs as the platform does. In the case of <input type=number> that API is the constraint validation API. If you don’t use it, but still want custom behavior, you are going to have a bad time, and that is not the platform’s fault (and certainly not the fault of any one element in it).