4 ms·

So, there's a number needed for a price estimate, but it's optional, and may be zero. I'm still having a bit of trouble here, but let's say it's "number of spar

So, there's a number needed for a price estimate, but it's optional, and may be zero. I'm still having a bit of trouble here, but let's say it's "number of spare parts". That's a number that could be zero, but if it's more than that you need to charge the customer extra. Let's say each spare part is an extra $5, so if the user enters "1", that's +$5. and if they enter "4", that's +$20. If they enter "0" that's +$0. And if the user enters "quux", that comes out as a blank value, so you treat it as "0" and modify the price by +$0. Which is...fine? What extra price did you want to add to the calculation if the user requested "quux" spare parts? Does anything else even make sense? If you need to tell the difference between an invalid value and a blank string, you should be able to use "checkValidity()". Sure, being able to retrieve the literal invalid value might have been nice to have in some ways, but I can't figure out why not being able to get it is a blocker for using the "number" type at all - even with the requested design constraints.

padseeker 4y ago
If they enter 'quux' or any invalid number then it should mark it as invalid, but if its blank then treat it as zero. You are correct the validity.valid or checkValidity() could be used in the right way to make the distinction between a blank non required value versus something that is invalid. I literally learned about that less than 24 hours ago. I'm glad I learned something. And I'm really appreciative the way that you asked, it's been kind of nasty in the comments section. However this not resolve the visual inconsistency issue for displaying error messages. Many complex forms have their own method of displaying error messages. It requires custom HTML and modifying the DOM. It rarely happens but once in a while the designer wants the invalid value mentioned in the error message. These are all issues that cannot be circumvented with the number input. I don't love avoiding the number input - but I prefer to keep my job and my client happy. I don't have final say on these kinds of things. Accessibility matters to me, but keeping my job matters more. I've lost a lot of time fighting with the number input.

padseeker 4y ago

If they enter 'quux' or any invalid number then it should mark it as invalid, but if its blank then treat it as zero. You are correct the validity.valid or checkValidity() could be used in the right way to make the distinction between a blank non required value versus something that is invalid. I literally learned about that less than 24 hours ago. I'm glad I learned something. And I'm really appreciative the way that you asked, it's been kind of nasty in the comments section. However this not resolve the visual inconsistency issue for displaying error messages. Many complex forms have their own method of displaying error messages. It requires custom HTML and modifying the DOM. It rarely happens but once in a while the designer wants the invalid value mentioned in the error message. These are all issues that cannot be circumvented with the number input. I don't love avoiding the number input - but I prefer to keep my job and my client happy. I don't have final say on these kinds of things. Accessibility matters to me, but keeping my job matters more. I've lost a lot of time fighting with the number input.