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.