Bug 59074 – Allow Opting Out of Number Input Localization

• Status: RESOLVED
• Resolution: WONTFIX
• Component: Forms

[Joseph Pecoraro]

There are some cases where <input type="number"> localization may
be undesirable. For instance in a credit card field, which accepts
a number that may contain a leading 0. This was possible in the
past, but with the localization changes the leading 0s were lost.

We can surround the localization with an ENABLE flag that allows a
port to opt out of the feature.

[Joseph Pecoraro]

Created attachment 90488 [details]
[PATCH] Proposed Fix

I'm not sure how ideal this test is. I assumed that platforms can localize
differently, and thus saying "PASS" if there were no leading 0s could be
a bit misleading. But I can easily change that, and switch to use the
normal js-test-pre/post helpers and formatting in that case.

[Maciej Stachowiak]

Comment on attachment 90488 [details]
[PATCH] Proposed Fix

r=me

[Maciej Stachowiak]

After discussing with Joe, I wonder if it might be better to remove the localization feature entirely. Using <input type="number"> for things like credit card numbers or social security numbers seems totally reasonable, and seems to be done in practice, but will be broken by the localized display and the leading zero stripping.

[Kent Tamura]

Credit card numbers and SSN are not suitable for type=number at all.  They are structured strings consisted of digits, and should be represented by <input type=text pattern=...>.  The number type is designed for IEEE754 floating point numbers.

Multiple developers and users asked me to support localized numbers.  They said using '.' for decimal separator was not acceptable in their locales.

Opt-out should be provided for page authors and/or UA users.  e.g. adding an HTML attribute, adding a CSS property, or adding a visible switch to enable/disable localization beside the text field.

[Joseph Pecoraro]

(In reply to comment #4)
> Credit card numbers and SSN are not suitable for type=number at all.
> They are structured strings consisted of digits, and should be
> represented by <input type=text pattern=...>.  The number type is
> designed for IEEE754 floating point numbers.

That sounds good, and is the same feedback I'm getting from others.
I don't think I'll be landing this patch, so I'm going to clear the flags
and mark it as obsolete.