With the new web-interface default that the browser number input is used by default we see problems entering numbers with digits after the decimal point. The reason is probably that the browser with a german (or austrian) locale insists that a number must contain digits after a decimal *comma* (german and austrian locales have a decimal comma not a decimal point). Which in turn cannot be parsed by roundup's mechanisms. So we can neither enter a decimal comma (because the cgi mechanisms cannot parse this) nor a decimal point (because the browser won't let us). When, e.g., entering "3.5" the browser issues the message "Please enter a valid value. The two nearest valid values are 3 and 4."

So I guess we should make the config-setting
use_browser_number_input
defaulting to "no" not "yes" as it currently doesn't work for non-english locales

It might also be that some browsers allow only integers or that I've made an error when refactoring the html generation with the new config variable. I've not investigated further. The browser in use is probably Chrome.

Hi Ralf:

> When, e.g., entering "3.5" the browser issues the message
> "Please enter a valid value. The two nearest valid values are 3 and 4."
 [...]
> It might also be that some browsers allow only integers or that I've
> made an error when refactoring the html generation with the new config variable.

Interesting. Are you sure the property is a number and not an integer? Integer
valued properties include "step=1" to make the number an integer. (You can enter
floating point numbers, but they will error.) The prompt about two nearest values
makes it sound like it expects an integer.

>So I guess we should make the config-setting use_browser_number_input
>defaulting to "no" not "yes" as it currently doesn't work for non-english
>locales

You note that using "3,5" to enter three and a half fails in locals that
use a decimal comma not a decimal point for a number property. It passes the browser
checks, but the number property parser doesn't handle a decimal comma.

I can think of four ways to handle this:

  1) set default for native input for numbers to off/false and update doc
     to discuss limitation when turning it on. This disables the native input
     for Numbers and Integers.

  2) add a WEB_USE_BROWSER_INTEGER_INPUT setting. Turn off WEB_USE_BROWSER_NUMBER_INPUT
     and set WEB_USE_BROWSER_NUMBER_INPUT to on. Then change the code for
     IntegerHTMLProperty::field() to use WEB_USE_BROWSER_INTEGER_INPUT.

  3) modify HTMLProperty::__init__ to replace ',' with '.' when setting value, or
     add/override HTMLProperty::__init__ in NumberHTMLProperty to modify the
     value replacing ',' with '.' before calling super.__init__(). This could be
     confusing to people in other locales though as the number will be displayed
     with a decimal point not a decimal comma.

  4) parse the floating value with a locale aware string -> float method.
     To prevent the same confusion as in #3, we would need to use a locale aware
     method to format plain() or field() values as well. I think we have the
     browser's locale available for this. Handling values assigned on the subject
     line in email might be an issue though as I am not sure if we have locale info
     there.

I'm ok with #1 and a request for patches to handle cases 2-4.

The native integer input is really useful on a phone as the keyboard changes
and is much easier to use.

More evidence for disabling the number type.

https://open-props-ui.netlify.app/components/inputs/text-field.html#numeric-vs-input-type-
number

recommends Using inputmode=number (with a suitable pattern). This should work for Integer
type although the error input isn't specific enough. It works on chrome but not on firefox
for mobile. Using inputmode=decimal for the Number type runs into the same decimal comma issue.

The recommendation from above is:

=====
You most likely don't need <input type="number">
While <input type="number"> may seem logical for numeric data it should only be used when
mathematical operations are needed on the input (which is... never). Data like credit card
numbers, IDs or social security numbers - are actually text that happen to be numeric rather
than mathematical values. Therefore, consider using <input type="text" inputmode="numeric"
pattern="[0-9]*"> instead.

You will have a bad time.

This triggers the numeric keyboard on mobile devices while avoiding the jank of number
inputs, such as:

  Unexpected value increments from scroll wheels
  Browser-specific validation differences
  Accessibility problems
  Removal of leading zeros
  Allows for some non-numeric mathematical characters
  It should probably be called <input type="math"> instead.

The British Government has a great article
(https://technology.blog.gov.uk/2020/02/24/why-the-gov-uk-design-system-team-changed-the-input-
type-for-numbers/)
about how bad input number is and goes in-depth. It's a very interesting read. 

====

Even though numbers can actually be intended for calculation (e.g. quantities/counts),
they can also be used for ordering which may not be calculable.

Roundup can still add an option to the config to make a number/integer input
into a plain text input even if we change the implementation to use inputmode.

Getting a numeric keypad on mobile handles 80% of the UX I was trying to get
but it seems only chrome (and safari) based browsers will work.

changeset:   8314:7ff47307b4b1

disables the native number pickers for the 2.5 release.

An admin can turn them on to generate more feedback on this ticket.
This ticket is referenced in CHANGES.txt.