Hacker News Reader

Comment by brundolf | Hacker News Reader

> 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

View on HN

> 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.

inputmode does localization:

> Fractional numeric input keyboard containing the digits and decimal separator for the user's locale (typically . or ,)

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

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.

Updating pattern to support float seems viable no?

Yep you can do that alongside this change

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.

This one works: `[0-9]+([\.][0-9]+)?`

> 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`

Doesn't work with i18n (some countries use , instead of . as the decimal separator).

Actually the majority of the countries use the comma. Though dot wins by population as China and India use it.

https://en.m.wikipedia.org/wiki/Decimal_separator

Fwiw the pattern can be dynamic. But at that point as others have noted might be better to have a dedicated validator

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).

`[0-9]+([\.,][0-9]+)?` then

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.

Switzerland is in Europe.

With 1'000'000 percent certainty.

Until you come to Spain and write

8.320.320,23

…

Reply on news.ycombinator.com