[Bug 12885] Add a new input type=numeric

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12885

--- Comment #9 from Ehsan Akhgari [:ehsan] <ehsan@mozilla.com> 2011-06-07 00:08:53 UTC ---
(In reply to comment #3)
> Another question is, what does the i18n story look like here? Some locales use
> different glyphs than '0' to '9'. Is that just a rendering issue? Or should
> different characters actually be submitted? What is standard practice in these
> locales when entering passport numbers and creditcard numbers?

Languages such as Arabic and Persian use their own Unicode code points to
encode their glyphs (U+0660-0669 for Arabic, and U+06F0-06F9 for Persian, see
<http://unicode.org/charts/PDF/U0600.pdf>).  There might be other languages
with similar digit glyphs.

The common practice for dealing with numbers in those languages is to display
the numbers in their native glyphs.  For example, if my passport number is
12345, I will write it as ۱۲۳۴۵ if I'm writing in Persian.

Many of the Arabic and Persian keyboard layouts will send the localized code
points when the user presses the respective key on their keyboard.  Ideally,
software which handles numbers should be able to accept and process numbers
entered in the localized digits seamlessly.  But unfortunately, there are lots
of applications out there which are broken in this regard, and do not treat
these two ranges as digit values.

The current i18n story with <input type=number> is sad (the localized digit
code points are not treated as digits).  I think that we should allow the UA to
accept localized digits too, and treat them internally as digits, not
characters, as the 0-9 digits are treated.  I also think that the default form
submission behavior should be to submit the number values in the Latin digit
code points, since that is probably what most web applications deployed on
servers understand.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 7 June 2011 00:08:57 UTC