Closed Bug 1253606 Opened 4 years ago Closed 10 months ago

Can't use dot/period as decimal mark for input type="number" in European configuration

Categories

(Core :: Layout: Form Controls, defect, major)

44 Branch
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 1199665

People

(Reporter: keul, Unassigned)

References

Details

Attachments

(1 file)

476 bytes, text/html
Details
Attached file Testcase
Europeans use comma and not the dot as separator in numbers.
While using computers, we frequently use the dot for 2 reasons:
- a lot of software don't support commas
- the numpad have a dot and not a comma in european keyboards

Google Chrome and Firefox both use the dot notation in the value attribute and for the returned value while displaying a comma.

But while Google Chrome accepts comma or a dot, firefox only accept the comma while using the keyboard/numpad.

I've set the severity on critical because Europeans can't type numbers with the numpad anymore and have to think about using comma.
Component: General → Layout: Form Controls
Product: Firefox → Core
jwatt, could we make the . keys insert the localized decimal separator instead of being a no-op / disallowed?
Flags: needinfo?(jwatt)
> the numpad have a dot and not a comma in european keyboards

"citation needed" :-)

I use a Swedish layout and it has a comma on the numpad, and no period.
A quick Google survey seems to indicate Polish, Spanish and German
layouts do to, fwiw.

So I kind of doubt this is a widespread problem.
If comma is the decimal sign in a country, then certainly keyboards
on sale in that country comes with comma on the numpad by default,
don't they?  Do you know of any country where this is NOT the case?
Flags: needinfo?(keul)
(In reply to Mats Palmgren (:mats) from comment #2)
> > the numpad have a dot and not a comma in european keyboards
> 
> "citation needed" :-)
> 
> I use a Swedish layout and it has a comma on the numpad, and no period.
> A quick Google survey seems to indicate Polish, Spanish and German
> layouts do to, fwiw.
> 
> So I kind of doubt this is a widespread problem.
> If comma is the decimal sign in a country, then certainly keyboards
> on sale in that country comes with comma on the numpad by default,
> don't they?  Do you know of any country where this is NOT the case?

I no longer live in the Netherlands, but at least 2.5 years ago, when I did, you would commonly get en-US keyboards on machines you bought. They have dots, and .nl uses ',' as a decimal separator.

Looking at Google images, it looks like French azerty keyboards also regularly use "." on the numpad - there's even a win xp soft keyboard screenshot that does it! Considering the reporter is from France, comment #0 seems reasonable to me, even if it might have been overly general if other EU locales don't do this.

TBH, I think it's a strict improvement to make this "just work" anyway. Chrome already does it, I wouldn't be surprised if IE behaved the same way.
(In reply to :Gijs Kruitbosch from comment #3)
> Considering the reporter is from France

Sorry, I should have been more specific/conservative: considering their bugmail address uses the .fr domain, it seems reasonable to assume they're from France in the absence of other information, thus...
I'm french, and french AZERTY keyboards have a dot on the numpad.
Exemple: http://ecx.images-amazon.com/images/I/41WIcVTXqKL.jpg

For information, most software like MS excel or LibreOffice calc convert the foot to a comma
Flags: needinfo?(keul)
(In reply to :Gijs Kruitbosch from comment #3)
> I no longer live in the Netherlands, but at least 2.5 years ago, when I did,
> you would commonly get en-US keyboards on machines you bought. They have
> dots, and .nl uses ',' as a decimal separator.

Interesting, but I don't understand why they would do that.
Surely they can get the same computer model but with .nl layout
instead if they wanted to.

> TBH, I think it's a strict improvement to make this "just work" anyway.
> Chrome already does it, I wouldn't be surprised if IE behaved the same way.

Yeah sure, I have nothing against accepting both comma and period
as "whatever decimal sign the page expects".
(In reply to Keul from comment #5)
> I'm french, and french AZERTY keyboards have a dot on the numpad.

Now that is truly insane.  A keyboard layout that goes against
the numeric format of the language it is intended for?
I consider that a hardware bug. :-)
You know what is insane? bépo (the french dvorak layout) also interpret the numpad dot as a dot. Android calculator use a comma while Windows10 calculator uses a dot. The numpad of all keyboard use a * for multiplication while the official multiplication operand is × or · (middle dot). The CSV, Comma Separated Values use semicolons and not commas in french versions. Most keyboards also have stagged keys due to the physical limitations of the typewriters (http://www.typematrix.com/2030/why.php).

So, we have 3 working solutions:
- convert dot to comma when it's typed (like said in comment 1)
- accept comma and dot when validating (and return dot in ele.value), and displays comma while value is changed trough commas or js or page reload. (like google chrome)
- convert comma to dot and use dot format validation (like Internet Explorer/Edge)

First one must be easy to do on actual code, second seems to be the logical one (and maybe more secure, like what happen when copy/paste operations?) and last one is... lacking respect for localization?
If someone typed 1,500 did they mean one thousand five hundred or 1 and a half. Accepting on validation seems error prone.
Aw, forgot that case...
How does others browsers manage that case in the US?
So we do like in comment 1, we convert dot to comma (when comma is used as separator).
Duplicate of this bug: 1322110
Duplicate of this bug: 1330691
Summary: Can't use dot for input type="number" in european configuration → Can't use dot/period as decimal mark for input type="number" in European configuration
Why is this ticket unconfirmed? Will it be solved or do I have to do workarounds every time?
Status: UNCONFIRMED → NEW
Ever confirmed: true
If you set attribute lang="nl-NL" on the input or any of its parents you can use both comma's and dots to input the decimal separator.

Seems like that should be the default behavior if you have set such a locale in your browser.
Possibly bug 1199665 is the way to go here. I'd like to hear what interested parties think about that though.
Flags: needinfo?(jwatt)
See Also: → 1199665
I use a French Firefox, on a French Windows, with French keyboard settings (Azerty keyboard). With this configuration, if I can't type numbers with the numeric keypad without having some developers write code for the input field, it's a bug. And I don't care who's to blame for it: I'm sorry for Firefox devs if they think Windows should convert "." to "," when typed from the numeric keypad, but they'll have to work around it anyway...

So my opinion is yes, do as Chrome, and accept "." as a valid decimal separator even for languages using ",".

Moreover, long discussions about thousand separators are pointless. I've never seen users input thousand separators in inputs. They can do it in documents which need to look nice, but they don't take the pain when inputting values. They leave the formatting to the software.
(In reply to Jonathan Watt [:jwatt] from comment #16)
> Possibly bug 1199665 is the way to go here. I'd like to hear what interested
> parties think about that though.

As an interested party I agree with above poster. Users generally don't type thousand separators. You should interpret the right-most comma or dot as a decimal separator regardless of locale.

A UX improvement is displaying thousand separators on blur and hiding them when the field has focus. Though that's not a show-stopper.

Also related, if there's support for inputmode="numeric" any user could use input type="text" and customize any behavior they want. Currently in Firefox you're forced to use input type="number" if you want a numeric keyboard on mobile.
I'm going to turn off our support for grouping (e.g. thousands) separators in bug 1509057. We can then fix this issue by fixing bug 1199665.
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1199665
You need to log in before you can comment on or make changes to this bug.