> The Gov.UK article mentions a possible solution: Using <input type="text" inputmode="numeric" pattern="[0-9]*"> is a nice option for integers, but it won’t work for floating point decimal numbers.
Note that there's also an inputmode="decimal" option which does have a decimal-point on Android and iOS
Really the answer is just, "don't use number most of the time, use regular text with the appropriate inputmode". The inputmode abstraction is better than the type abstraction; it lets you specify what you really care about most of the time (mobile keyboards) without a bunch of extra constraints bundled in there
> The inputmode abstraction is better than the type abstraction
No. inputmode has no localization, or validation.
If your locale uses period as a decimal mark, but mine uses a comma, you can type "42.5" while I type "42,5" and they are both the same numbers (both evaluate to 42.5). You also get localized front end validation for free if you use type=number, but you’ll have to implement it your self with inputmode.
As for validation- you can get reasonably far with the `pattern` attribute, but many apps do validation with JavaScript anyway.
The benefit of inputmode is specifically that's it's less opinionated- it lets you give instruction to the system keyboard (which is a feature you can't otherwise provide yourself), but leaves it to you to handle everything else as you see fit.
Only on the soft keyboard, not with the value it self. So for users with hardware keyboards it will matter if they type 42.5 or 42,5 (i.e. the browser sees those as different values under different locales).
And this becomes an even bigger issue if you use pattern for validation (as you will have to sniff for the user’s locale conditionally adjust the pattern; good luck with that).
You also get this and validation error message localized with <input type=number>
EDIT: To clarify further. If I type 42,5 on my browser with an Icelandic locale, but your website uses inputmode=decimal, then my input will evaluate as NaN when you run `inputElement.valueAsNumber`. On the other hand you will get 42.5 if you properly set the type=number.
Sure, so that's a good thing to think about when implementing your logic. But it's not like you don't have to think about localization at all if you use type="number", and imo the downsides outweigh the upside of having the browser handle this one case for you
I feel like you might be underestimating the difficulty of localization. There are way more customary ways to write numbers then you can think of (there is probably a Falsehoods Programmers Believe About Numbers out there which addresses the innumerable ways people write numbers).
I also feel like you are underestimating the amount of localization that the browser actually does. Yes you still have to do some localization, but there is a whole issue that the browser does for you if you use the correct attributes. There are way more upsides which you might be unaware of.
Not being a front-end dev, it does seem trivial, but using [0-9\.]* means you can have 1.2.3. You can tighten that regex up, but I imagine that either doesn't fly with mobile keyboard hinting or screen readers trying to hint what a correct value is.
> I imagine that either doesn't fly with mobile keyboard hinting or screen readers trying to hint what a correct value is
The `pattern` attribute isn't used for anything except validation as far as I know; the mobile keyboard at least is entirely driven by `inputmode` and/or `type`
It will work until you have someone from Europe get in touch early in the morning to complain your form doesn’t accept decimal commas (although they may well just roll their eyes again and mutter something about how Anglos don’t bother supporting their international users properly).
Getting into the weeds here though. The advantages/disadvantages of regex-based validation are beside the original point (and anyway I prefer doing validation in JS most of the time, for various reasons, but that's also out of scope)
> I prefer doing validation in JS most of the time
As you should! :) Preferably by using a parser-generator library. Validation is basically just an error mode of parsing, and parsing things with regexes is not only unreadable, but also loses a lot of valuable information about the error.
Luckily it is easy to do validation with javascript if you properly set type=number:
if (Number.isNaN(input.valueAsNumber)) {
// If only this message could also by localized
input.setCustomValidity("Please type a number");
} else {
input.setCustomValidity("");
}
But double luckily, we don’t even need to do this as we also get this for free, and as a bonus the message is localized.
Note that there's also an inputmode="decimal" option which does have a decimal-point on Android and iOS
Really the answer is just, "don't use number most of the time, use regular text with the appropriate inputmode". The inputmode abstraction is better than the type abstraction; it lets you specify what you really care about most of the time (mobile keyboards) without a bunch of extra constraints bundled in there