4 ms·

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

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).
- padseeker 4y ago
  Not returning the invalid value is in fact the fault of the platform. On more than one occasion I've been asked to put the invalid value in the error message. If you are using a framework like React or Angular, which I do a lot, then you are using a different approach to validation. Typically you aren't using the DOM API, each framework has it's own approach. You can use the DOM but that is additional work and deviates from the tools provided by each of these frameworks. I probably should have stressed that much of my work is spent using these frameworks. The angular form API is hot garbage but again it's not my choice, I have to use what's been selected. I'm a big fan of React, I have not explored all the options available with React and accessing the value. Typically you aren't using checkValidity when you use React.
  - runarberg 4y ago
    I use these frameworks as well, and generally when I’m scouting for libraries I make sure they work well with the platform. A good form validation for react, angular or vue will most likely use the constraint validation API under the hood, if they aren’t, then they probably provide most of the same features (or maybe it isn’t such a good library). Rolling your own isn’t too hard either. In my job I rolled my own useValidation() for vue in less then 150 lines of TypeScript If you need the actual invalid value for some reason (which is really rare IMO) you might have a point, but otherwise <input type=number> is a perfectly cromulent element.

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).

padseeker 4y ago
Not returning the invalid value is in fact the fault of the platform. On more than one occasion I've been asked to put the invalid value in the error message. If you are using a framework like React or Angular, which I do a lot, then you are using a different approach to validation. Typically you aren't using the DOM API, each framework has it's own approach. You can use the DOM but that is additional work and deviates from the tools provided by each of these frameworks. I probably should have stressed that much of my work is spent using these frameworks. The angular form API is hot garbage but again it's not my choice, I have to use what's been selected. I'm a big fan of React, I have not explored all the options available with React and accessing the value. Typically you aren't using checkValidity when you use React.
- runarberg 4y ago
  I use these frameworks as well, and generally when I’m scouting for libraries I make sure they work well with the platform. A good form validation for react, angular or vue will most likely use the constraint validation API under the hood, if they aren’t, then they probably provide most of the same features (or maybe it isn’t such a good library). Rolling your own isn’t too hard either. In my job I rolled my own useValidation() for vue in less then 150 lines of TypeScript If you need the actual invalid value for some reason (which is really rare IMO) you might have a point, but otherwise <input type=number> is a perfectly cromulent element.