spotted by @Betree while reviewing opencollective/opencollective-frontend#3613

Initially, I had a look around and I came across this blog post on how <input type="number"> validation is implemented differently across browser vendors and also based on the locale.
For example, on my default browser (macOS, Chrome 80), I can't seem to be able to get a comma into the field.

However, I was able to reproduce the error behaviour you pointed out in Firefox 73 and Safari 13.

And when I added a lang attribute (Norwegian for example) to the input element in components/InputField.js lang=nb commas were accepted in the input in Firefox 73 as well as periods.

But the error behaviour still persisted in the other browsers I had tried previously.

We could try adding lang attributes that would allow commas&periods to the input fields based on the currency set, however, behaviour across browsers may not be consistent.

@znarf also shared something on this topic the other day: https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-type-for-numbers/.

There are two things here:

• The question about localization, using , vs .. I've made some changes in our StyledInputAmount, when used as a controlled component with parseNumbers I believe the behavior is pretty comprehensive (but I haven't tested it on a lot of browsers):

It probably won't be perfect, but even just relying on the native input and warning if the number is not valid is, in my opinion, an acceptable solution.

• Another problem, that is to me the really problematic part here, is that all the options after the invalid one gets removed. Let's say you have [ 10, 20, 30, 40, 50 ] and you try to add a comma or a dot on 30 then it should never remove the options after (40 and 50).

So for me the two things that we need to do here are:

• Have a clear error message if a number is not formatted properly
• If a number is invalid, don't remove the entries after it

I'll get on this and submit a PR asap.

• Another problem, that is to me the really problematic part here, is that all the options after the invalid one gets removed. Let's say you have [ 10, 20, 30, 40, 50 ] and you try to add a comma or a dot on 30 then it should never remove the options after (40 and 50).

However, for this, I haven't been able to recreate this behaviour unless I'm missing something/misunderstanding you. Like in the example you shared originally it only appears to remove the invalid value being edited and doesn't affect the values after it. (like in your example, out of [ 5, 25, 66] when you edit the 25 that makes it invalid, the 66 seems to remain intact.)

@brymut Yes you're right, I was not remembering the behavior correctly. So to edit my second point:

• If a number is invalid, don't remove it but eventually show a warning/an error message

Should ideally be resolved with #3438

This also happens when submitting an expense.

This is still happening with expenses. We need to have a look at this.