Hi,
The current WebKit/Blink behavior is:
- Accept both of the ASCII digits and localized digits
- Accept both of the standard decimal point '.' and a localized decimal
point
- Not accept grouping separators and don't show grouping separators
We showed grouping separators in the past. But we stopped it because
grouping separators disturb some use cases.
We accepted entering grouping separators in the past. But we stopped it
because users had to know their locale correctly. e.g. "1,234" has
different meaning in French locale and English locale if we support
grouping separators.
On Wed, Feb 19, 2014 at 8:09 AM, Jonathan Watt <jw...@jwatt.org> wrote:
When implementing <input type=number> for Mozilla I decided to display the
value to the user using the grouping separator (generally the thousands
separator) of the users locale. So, for example, if the input's value is
1234 and the user's locale is English, it is displayed to the user as
"1,234".
This is causing a problem for at least media wiki, because they use <input
type=number> for year input. For example:
https://en.wikipedia.org/w/index.php?title=IRIX&action=history
https://en.wikipedia.org/wiki/Special:Contributions/newbies
The question is, should I change Mozilla's implementation to stop
displaying the internal value using grouping separators, or is it wrong to
use <input type=number> for year input. I'm erring on the former, but I'd
like to solicit others' thoughts on this matter.
I should also note that I can still allow the implementation to accept
input from the user that contains grouping separators, even if when the
internal value is set/changed the visual result will be updated to a
string
that does not contain grouping separators.
--
TAMURA, Kent
Software Engineer, Google
