'“e” is a valid part of a number, I don’t understand why you have issues with it.'
That's a very programmer-centric take. A very, very programmer-centric take. The use of "e" for exponent in scientific notation is a very computer-oriented take on the problem. Such other places as you may have seen it used are leaks from the computer representation. Nobody else sees numbers that way; scientific notation is generally written as 3.278·10³⁶ (only with better superscripts), which is how it is taught in schools for the most part. There are many contexts where I would say it is not a valid part of a number, because I don't expect my users to know scientific notation, let alone an idiosyncratic rendering of it used only for historical reasons in certain niches of the programming world.
I'm pretty sure it's just 'calculator notation' and not a leak from the computer representation, but rather done because of the limited space available (at least on older calculators).
This pre-dates the first hand calculator I know of, the early HP's from 1968. These machines used the same notation as the HP-35 pictured below (https://www.hpmuseum.org/rpnvers.htm#num).
The HP-35 calculator came out in 1972. According to the page below, the scientific notation used is of the form
1.234-8
i.e., without the E (see the second row of the gallery).
> The use of "e" for exponent in scientific notation is a very computer-oriented take on the problem. Such other places as you may have seen it used are leaks from the computer representation. Nobody else sees numbers that way;
It’s a pain in the arse to write, though, which is why quite a lot of scientists and engineers use e even though they don’t know anything about programming and are very, very far from being CS people.
I don’t know anyone who would enter 310^8 naturally in an input field (besides, using for multiplication itself comes from ancient technological limits, but nobody uses the proper multiplication sign either).
So yes, you need to support e for scientific notations in any input field that can be used for large or small numbers.
> scientific notation is generally written as 3.278·10³⁶ (only with better superscripts), which is how it is taught in schools for the most part.
That’s how we write it in LaTeX and our reports, articles, and such. And presentations if you’re lucky. But again, nobody writes that if presentation does not matter enough to go through the hassle. Certainly not in plain text where you’d have to use Unicode characters, at which Windows is completely incompetent.
I’d hope so, it’s basically taught in the 2nd grade (group 4 here), along with how to read and write and it seems people still remember that ok. Google is also immensely helpful if people forget how to read numbers. /s
I guess the point is, you can parse it and output it in whatever format is appropriate, regardless of how it is stored.
States are also taught in schools and yet many people think New Mexico is outside the US.
If you are creating software for engineers, that's a fair assumption to make (that will understand what an exponent is). The public at large? Absolutely not.
That is a convention only commonplace on graphical calculators and modern scientifics with formatted infix entry. A traditional scientific just shows an exponent in a reserved display location.
A large segment of older adults have never used them.
I’ve been seeing it since I was a child on everything from cheap little eight digit calculators to expensive calculators with rolls of paper to graphing calculators.
We call them decimal points. Most software uses full stops (aka periods, because that's what's on the keyboard), but decimal points are normal in typeset and handwritten maths.
yea and more! they use low-dot (period) when multiplying variables, and Roman digit for 1, and does not use the "-rd" ending names for the power of 1000: milliard, billiard…
> Using a number input, these things are handled for you.
That's not my experience. I used a number input field for actual numbers (i.e. amounts of currency), but on some phones (specifically Samsung phones), it would show up with a full stop for decimal points (even though the locale was explicitly set to one with commas for decimal points), and users were unable to enter decimal numbers on Samsung phones.
Unfortunately, the handling of the number input field is extremely browser/OS dependent.
Eventually, I decided to go for text input, with numeric for inputmode, and simply interpret both "." and "," as decimal points (not permitting the user to use thousand separators, but few people would do that for input anyway). A bit awkward, but it worked.
Note: Using text and inputmode=numeric did not technically solve the issue of Samsung phones persistently showing the wrong keypad, but the JavaScript interpretation was the real solution to the problem.
When you say "on Samsung phones" do you mean the native Samsung web browser, or any browser on a Samsung phone? Like does this happen on Firefox or Chrome on the Samsung phone?
I will admit, my testing was limited to the native Samsung web browser and to a capacitor made native app, where the problem occurred. It is very possible that Firefox and Chrome on the phone would behave as expected, but I never tested them, since users were experiencing the problem with the other versions of the app, and I needed to find a solution.
Initially, I thought it was a problem with converting a React app to a native app with capacitor, but I tried the same Android app on a different (non-Samsung) Android phone and it did not have the problem (iOS similarly did not have the problem, both web and native version).
Just read the article. A big part of the article that I can summarize is I don't set the requirements, someone else does. Every project is different. You might be fine with just integers. However I've been tasked with much more complicated requests.
There may be exceptions but I guarantee you in most cases the product manager doesn't want the letter e.
My app was built with Rails, and if you enter the value "3.9e3" which represents the number 3900, Ruby will simply use the number 3 and toss the rest of the value away. Do you really want to add special functionality on the back end to covert that value into the actual value? I surely would not.
Also plenty of people use javascript without it being a Single Page Application. Keenforms is not a SPA, we use React for certain pages, but I wanted to keep server side rendering. Using Javascript is not exclusive to SPAs.
(int) ‘3.9e3’ gets parsed correctly in php, perhaps use a language built for the web and not a general purpose language, or a framework that knows how to parse exponential notation? It sounds like Rails doesn’t understand how software works.
I’ve also been messing with forms for twenty-something years, and I’ve never run into these sorts of problems but I understand the problems you are facing, especially after googling these problems and their solution in regards to Rails. I’ve heard it’s a productive language, but when you have to solve such simple problems, maybe not?
Sorry, I don’t mean to bash on your chosen language which is probably how this is coming across. I’m genuinely intrigued by these stack overflow answers.
Just because you didn't run into these problems doesn't mean they don't exist. The clients I do work for have very complicated requirements and expect a lot of dynamic interactions from the forms they pay for. It could be a non profit trying to determine if a new client's family qualifies for federal benefits based on family size and income level. It could be a gas pipeline company trying to calculate how much natural gas they can deliver on a 60 day contract during summer months versus winter months. It could be calculating the medication dosage per body weight for a pharmaceutical company. There was the life insurance example which I mentioned in the article.
Ruby will parse "3.9e3" properly. However Ruby on Rails param parser tries to prevent bad data from entering the system. So the e gets sliced off. There are things that you can do to prevent data from being entered that way.
However like I mentioned in the article and commented on multiple times its not always my choice. And overwhelmingly the product managers and stake holders I interact with would prefer to not see numbers submitted in scientific notation form. There's no reason why you would want to submit your age like that. It's highly unlikely anyone would need a product quantity value in that format.
And maybe most importantly the people who pay tell me all the time they don't want it. Does that make sense?
With ROR it might be transformed via the params parser. If you enter the code below in plain old Ruby environment, like irl or the console, it will properly parse it;
"3.9e3".to_f
=> 3900.0
Something happens when submitting web based params. I'd be curious to see what other back end languages and frameworks do.
raises "invalid value for Integer()". Really, nothing to see here. Ruby just doesn't treat "3.9e3" as a valid string for an integer (which arguably is correct IMHO)
> “e” is a valid part of a number, I don’t understand why you have issues with it.
I think people would have fewer issues with it if the browser transparently converted it, either on entry or when calling .value. It's a somewhat obscure case that's easy to get wrong.
For example if I enter 104e4 into a number input with ID test, I get these results in Chrome/Edge:
> $("test").value
'104e4'
> parseInt($("test").value)
104
> parseFloat($("test").value)
1040000
> $("test").value - 0
1040000
Same with decimal points. It's a weird foot-gun because the solution is only half-there.
If you know you're dealing with a number, use `.valueAsNumber` instead of `.value`. Value is a string per the specification, but `.valueAsNumber` does what you expect (for datetime there is also `.valueAsDate`).
The form is submitted to the server using `value`, not `valueAsNumber`. Or maybe you'd prefer all forms to be submitted using JavaScript instead of just using <form action>?
That is up to the developer. Most devs I know prefer to intercept the submit event, convert the form to a JSON object and send the JSON to the server. However if you don’t want to intercept the submit event, then it is up to your server to parse the eccentric inputs, the browser will send them (almost) as is (almost, as in it will consider the locale, e.g. 13,37 will be sent as 13.37 for some locales).
It depends on what you are using on the back end. So for the record my own app's back end is Ruby on Rails.
If you enter the value "3.9e3" which represents the number 3900, Rails param parser will simply use the number 3 and toss the rest of the value away. Do you really want to add special functionality on the back end to covert that value into the actual value? Most of us would not.
I'd be curious to see how other languages and frameworks handle this issue but the e for many of us is a real problem. Most people aren't even aware of it, and learn the hard way.
That's the Javascript's "everything is a single type, but we use types for polymorphism" footgun, and it's a way more general problem than this. Anyway, every JS developer has been harmed by it and knows about it.
If I understand correctly. JavaScript itself didn't even think '111,2' is a proper float number. Only decimal point is allowed. So by using it, your input already bugged out. The number input is just wild and it did not support transform the input to a proper number for you.
A proper number is 123.456,78 in large parts of Europe. If I can't put that into your number control when my browser locale is set to Dutch, your custom number input has failed as much at the broken input we're talking about.
It's not just the specific separators, of course; in India such a number is often written like 1,23,456.78 for example, grouping numbers entirely different. Don't assume everyone is American.
> JavaScript itself didn't even think '111,2' is a proper float number. Only decimal point is allowed. So by using it, your input already bugged out.
I may be misunderstanding the gist of your comment, but surely the only "bugged out" behavior would be to try and call parseFloat on the value of the input directly without accounting for localization. Why should JavaScript's number representation affect whether or not I can enter numbers in the way I do everywhere else? The browser offers an API[1] for displaying numbers in a specific locale after all, though it's annoying that you either have to hack something together using Intl.DateTimeFormat.prototype.formatToParts or use a third party library in order to parse them.
If you use a locale where commas are decimals and use number input, it is a decimal in the code. I have my computer and phone set to en-NL, which has that style of numbers.
A SPA is calling a backend as well... and the backend (SPA or not) still needs to handle the number locale (comma versus decimals), unexpected 'e', etc. Not sure what about this is a JS problem.
FWIW, I’ve never seen an ‘e’ from a number input on the PHP side, probably because it is parsed correctly. I’ve also never seen it from ‘.valueAsNumber’ on the js side either, except rendering big/small numbers but the internal representation was still correct. Using IntlFormat solved that problem IIRC. If you are passing it around as a string, then I imagine it’s a bigger problem.
Can you give an example of an invalid value in a number input that you can't retrieve, and explain how that's worse than the invalid value in a text field? I'm having trouble figuring out exactly what the problem is there.
As for min/max limits being bypassed and needing to do server-side validation also... well, yes? But, don't you have to do that even if you're using javascript for validation? The user could modify the DOM directly and replace the form control with one of their choosing that doesn't have javascript listeners, or submit a request from the javascript console, or even figure out all the required cookies and everything and submit a request with arbitrary params using `wget`. The server must always validate client input.
Thank you so much for asking so kindly. I'd actually be thrilled to do that.
I built a form that gave a price estimate for a product, and it would change as you modified inputs on the screen. One of the requests was to treat a blank number input as a zero. That particular input was not required. The ideal situation would have been to default the number input to zero, but the product manager wanted to let the user leave it blank.
The problem became evident when the calculations to generate the price estimate treated a blank value and an invalid number value the same. You always get a blank string whether its blank or an invalid number value. To be honest I really hate whoever made this decision with the W3C committee or whoever it was. It makes zero sense that you let a user put it bad data but you won't give the invalid value via javascript. This was a deal breaker. We had to switch to the text input.
It should also be noted that the built in validation for the number input takes precedence over whatever javascript written to generate an error message. There were complaints from the designer about this issue. It may seem like a petty thing but again I don't get to make these decisions, they are made by the client.
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.
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.
Thanks for the write-up. I'd be interested to know what the actual reasoning in the complaints were though that Keenforms does not use number inputs. Was it just standards pedantry or were there some actual usability issues that were caused by that descision?
You mentioned inputmode="numeric" a few times as a possible solution. Does Keenforms make use of that?
I'll admit I name dropped my own product a lot. As a programmer I'm a little embarrassed, bordering on shameless. But as a single founder it means I have to do marketing, which means I have to be a little shameless.
