3 ms·

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.

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.