This was was cloned from bug 12885 as part of operation convergence.
Originally filed: 2011-06-03 22:28:00 +0000
Original reporter: Adrian Bateman [MSFT] <adrianba@microsoft.com>

================================================================================
 #0   Adrian Bateman [MSFT]                           2011-06-03 22:28:37 +0000 
--------------------------------------------------------------------------------
HTML5 defines input type=number which allows developers to create an input element for collecting valid real numbers. Input type=number is insufficient for telephone numbers because telephone numbers may have special formatting or allow characters which are not numeric. For this there is a specific telephone input type.

There are other cases when developers need to optimize for numeric input but they don't want to require a valid floating point number. A prime example of this is input elements for US zip codes which can have leading zeros and some non-numeric characters. Other use cases for numeric input which may not actually be a real number is a credit card number, passport ID number or product sku number.

Webkit already attempts to solve this problem by displaying a numeric keyboard when the developer has set the pattern attribute to "[0-9]*" or "\d*". (Reference: http://developer.apple.com/library/ios/#documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/KeyboardManagement/KeyboardManagement.html#//apple_ref/doc/uid/TP40009542-CH5-SW1) This is a mainstream scenario and developers should have a declarative way to indicate that they want a text field optimized for numeric input.

We propose a new input type for this scenario, input type=numeric.  This type would be exactly the same as the text and search state (http://dev.w3.org/html5/spec/states-of-the-type-attribute.html#text-state-and-search-state). The difference between the Numeric state and the Text and Search states is that on platforms which support soft keyboards optimized for entering different data types, the Numeric state might result in a soft keyboard optimized for entering numeric digits. 

The difference between the Numeric state and the number state (http://dev.w3.org/html5/spec/number-state.html#number-state) is that the numeric state does not require that the value be a valid floating point number.  It also does not support any of the methods/attributes which depend on the value being a valid number such as valueAsNumber, stepUp and stepDown. Developers can still use the pattern attribute if they want client side validation.
================================================================================
 #1   Jonas Sicking                                   2011-06-03 22:52:38 +0000 
--------------------------------------------------------------------------------
I take it '.', '+' or '-' characters wouldn't be allowed in this new control?

In general this sounds like a reasonable idea to me. *Possibly* we'd want something which doesn't sound so similar to "number" as to avoid confusion and mistakes.
================================================================================
 #2   Tab Atkins Jr.                                  2011-06-04 00:14:59 +0000 
--------------------------------------------------------------------------------
I like the idea, with the same naming concern as Jonas.  Maybe type="digits"?
================================================================================
 #3   Jonas Sicking                                   2011-06-04 00:25:15 +0000 
--------------------------------------------------------------------------------
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?

I know Ehsan worked on i18n issues with regards to numbers in Gecko so he might be able to shed some insight.
================================================================================
 #4   Paul Cotton                                     2011-06-04 16:12:08 +0000 
--------------------------------------------------------------------------------
>Another question is, what does the i18n story look like here?

How does the existing input type=number handle the I18N story for numeric digits?  Wouldn't the solution here be the same?

/paulc
================================================================================
 #5   Henri Sivonen                                   2011-06-04 16:53:17 +0000 
--------------------------------------------------------------------------------
It seems to me that type=tel is already what you are asking for:
http://www.whatwg.org/specs/web-apps/current-work/#telephone-state
================================================================================
 #6   Aryeh Gregor                                    2011-06-05 19:26:11 +0000 
--------------------------------------------------------------------------------
(In reply to comment #0)
> There are other cases when developers need to optimize for numeric input but
> they don't want to require a valid floating point number. A prime example of
> this is input elements for US zip codes which can have leading zeros and some
> non-numeric characters. Other use cases for numeric input which may not
> actually be a real number is a credit card number, passport ID number or
> product sku number.
> 
> Webkit already attempts to solve this problem by displaying a numeric keyboard
> when the developer has set the pattern attribute to "[0-9]*" or "\d*".
> (Reference:
> http://developer.apple.com/library/ios/#documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/KeyboardManagement/KeyboardManagement.html#//apple_ref/doc/uid/TP40009542-CH5-SW1)
> This is a mainstream scenario and developers should have a declarative way to
> indicate that they want a text field optimized for numeric input.

There are several other ways you'd like to optimize soft keyboards, and it would be nice if authors could do those too.  Useful behaviors might include:

* "numeric": Use numeric keyboard.  Zip codes, credit card numbers, etc.
* "regular": Use letter keyboard, initially capitalized but de-capitalizing after the first letter.  This is the usual default behavior, suitable for regular text.
* "uppercase": Use letter keyboard but stay capitalized as the user types, instead of de-capitalizing after the first letter.  Useful for states, currency codes, and other abbreviations.
* "capitalized": Start capitalized, decapitalize after the user types the first letter, recapitalize at the beginning of a new word.  Useful for proper names, cities, etc.
* "address": Start with numeric keyboard, behave as "capitalized" after the user hits space.  Useful for street addresses (and probably not much else).

I know that some inputs in native Android apps behave like I describe "capitalized".  Currently pattern="" can't let you do that, since it's case-insensitive.  I haven't seen the "uppercase" or "address" behaviors, but they'd be handy.

I'm not sure adding new types is the right way to go here, though.  Using a different attribute might make more sense, maybe expect="" or hint="" or keyboard="".  All the existing types except search really dictate the input's functionality a lot more than just a soft keyboard hint.  E.g., type=tel could provide suggestions from the user's address book on a smartphone.

(In reply to comment #1)
> I take it '.', '+' or '-' characters wouldn't be allowed in this new control?

Adrian can correct me if I'm wrong, but it sounds to me like there are supposed to be no validation requirements.  It's just a hint to switch keyboards.

(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?

In my experience, almost all locales use the digits 0-9 for things like credit card numbers and phone numbers.  But since the proposal is that this is just a hint for switching keyboards, submission should be the same as type=text, and the user should be able to enter anything they like.

(In reply to comment #4)
> How does the existing input type=number handle the I18N story for numeric
> digits?  Wouldn't the solution here be the same?

For type=number, the value must be a valid floating-point number at all times, and the format it's submitted in is (more or less) well-defined.  So the UA can display the number in whatever format it likes.  In this proposal, it sounds like the UA is not altering the user's input at all for submission, so that solution is inapplicable.

(In reply to comment #5)
> It seems to me that type=tel is already what you are asking for:
> http://www.whatwg.org/specs/web-apps/current-work/#telephone-state

That isn't meant to handle things like zip codes, credit card numbers, etc.  UAs might do confusing things like autocomplete to phone numbers from your address book.
================================================================================
 #7   Adrian Bateman [MSFT]                           2011-06-06 16:45:28 +0000 
--------------------------------------------------------------------------------
(In reply to comment #6)
> I'm not sure adding new types is the right way to go here, though.  Using a
> different attribute might make more sense, maybe expect="" or hint="" or
> keyboard="".  All the existing types except search really dictate the input's
> functionality a lot more than just a soft keyboard hint.  E.g., type=tel could
> provide suggestions from the user's address book on a smartphone.

It could be another attribute, although I worry about the complexity of having both type and a hint and having to work out what to do for each combination. The semantic information about the expected data might be used for other input means such as hinting to the heuristics for speech recognition.

> (In reply to comment #1)
> > I take it '.', '+' or '-' characters wouldn't be allowed in this new control?
> 
> Adrian can correct me if I'm wrong, but it sounds to me like there are supposed
> to be no validation requirements.  It's just a hint to switch keyboards.

Right - we didn't intend there to be any validation - pattern="" can be used for that. 

> (In reply to comment #5)
> > It seems to me that type=tel is already what you are asking for:
> > http://www.whatwg.org/specs/web-apps/current-work/#telephone-state
> 
> That isn't meant to handle things like zip codes, credit card numbers, etc. 
> UAs might do confusing things like autocomplete to phone numbers from your
> address book.

Agreed - I think it would be a mistake to try to re-use the telephone state for arbitrary numeric input.
================================================================================
 #8   Aryeh Gregor                                    2011-06-06 19:12:42 +0000 
--------------------------------------------------------------------------------
If it were a separate attribute, it would be defined as valid only for the text and search types, just like attributes like placeholder are only defined as valid for particular types.  It could be specified that it would be ignored for other types.
================================================================================
 #9   Ehsan Akhgari [:ehsan]                          2011-06-07 00:08:53 +0000 
--------------------------------------------------------------------------------
(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.
================================================================================
 #10  Jonas Sicking                                   2011-06-07 02:52:30 +0000 
--------------------------------------------------------------------------------
So given that we want special behavior for digits here, in that non-latin digits are transformed to latin digits, we should probably use a new type rather than simply a keyboard-hint attribute.
================================================================================
 #11  Henri Sivonen                                   2011-06-07 05:43:52 +0000 
--------------------------------------------------------------------------------
(In reply to comment #9)
> 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.

Browsers are already supposed to be allowed to display type=number in localized ways as long what shows up in the DOM and what goes over the wire uses Basic Latin digits and period as the decimal separator. (The spec isn't particularly clear on this.)

If the user is shown Persian digits in type=number, it's obvious to the user (who reads Persian) what is going on. Localizing the decimal separator to a comma might be more of a problem, because a Finnish user would expect English-language sites to use a period as the decimal separator, so there'd be doubt about whether a comma is a decimal or thousand separator on an English-language site if fi-FI browser UI changed all type=numbers to present a numbers with a decimal comma.

I think type=number should change its localization behaviors depending on the language of the element (per http://www.whatwg.org/specs/web-apps/current-work/#language). The downside is that browsers would have to contain the localization capabilities for all known locales instead of their own UI locale. For number formatting, the relevant libs probably support all known locales anyway, so this shouldn't be too much of a problem.
================================================================================
 #12  Jonas Sicking                                   2011-06-07 08:15:01 +0000 
--------------------------------------------------------------------------------
I agree with comment 11, but I'm not sure that it's relevant to this bug? Or are you suggesting that type=number solves the relevant use cases?
================================================================================
 #13  Adrian Bateman [MSFT]                           2011-06-07 16:50:54 +0000 
--------------------------------------------------------------------------------
(In reply to comment #10)
> So given that we want special behavior for digits here, in that non-latin
> digits are transformed to latin digits, we should probably use a new type
> rather than simply a keyboard-hint attribute.

I'm not sure special digit handling is appropriate for numeric. That might be appropriate for type=number but in this proposal we're suggesting that the input be free-form but focused on digits. A hint might therefore be appropriate.
================================================================================
 #14  Ehsan Akhgari [:ehsan]                          2011-06-07 17:17:15 +0000 
--------------------------------------------------------------------------------
I can't see why having free-form digit input would mean that we shouldn't perform special handling for Arabic and Persian digits...
================================================================================
 #15  Adrian Bateman [MSFT]                           2011-06-07 17:20:47 +0000 
--------------------------------------------------------------------------------
Why not always do that then? This could happen for type=text too and so doesn't need to be influenced by the type.
================================================================================
 #16  Jonas Sicking                                   2011-06-07 19:35:14 +0000 
--------------------------------------------------------------------------------
It would probably be surprising for a arabic website that when the user writes a bunch of text and a arabic ۴, that all the text would remain intact, but the ۴ was changed into a 4. Consider the presumably quite common use case of blog comments suddenly appearing with latin numbers rather than arabic ones.
================================================================================
 #17  Ehsan Akhgari [:ehsan]                          2011-06-07 20:15:57 +0000 
--------------------------------------------------------------------------------
Yes, Jonas is correct in comment 16.  We definitely don't want to do this everywhere, since there are cases where maintaining the exact characters entered in the textbox (for type=text) is crucial; for example, when you want to enter this sentence:

"123 in Persian digits is ۱۲۳."

Note that I think my suggestion in comment 9 should also be applied to type=number, but that is out of scope for this bug.
================================================================================
 #18  Henri Sivonen                                   2011-06-08 05:05:01 +0000 
--------------------------------------------------------------------------------
(In reply to comment #12)
> I agree with comment 11, but I'm not sure that it's relevant to this bug? Or
> are you suggesting that type=number solves the relevant use cases?

No. I'm suggesting that we shouldn't try to address i18n sadness of type=number by introducing other types. There may be other reasons to introduce new types.
================================================================================
 #19  Volker Krebs                                    2011-06-08 09:58:50 +0000 
--------------------------------------------------------------------------------
I think that allowing the pattern attribute for type=number is a good idea. The specification should not define what a valid floating point number is, like it does here
http://www.w3.org/TR/html5/common-microsyntaxes.html#valid-floating-point-number
================================================================================
 #20  Jonas Sicking                                   2011-06-08 12:41:22 +0000 
--------------------------------------------------------------------------------
(In reply to comment #18)
> No. I'm suggesting that we shouldn't try to address i18n sadness of type=number
> by introducing other types. There may be other reasons to introduce new types.

Ah!

Comment 0 describes why <input type=number> doesn't solve the use cases here (for example initial 0's are stripped).

i18n is the reason that <input type=text> doesn't solve the use cases (we want transformation of numbers to latin numbers).
================================================================================
 #21  Ehsan Akhgari [:ehsan]                          2011-06-08 17:59:23 +0000 
--------------------------------------------------------------------------------
To avoid confusion, I've filed bug 12915 to request <input type=number> to accept Arabic and Persian digits.
================================================================================
 #22  Adrian Bateman [MSFT]                           2011-06-09 14:50:54 +0000 
--------------------------------------------------------------------------------
(In reply to comment #17)
> Yes, Jonas is correct in comment 16.  We definitely don't want to do this
> everywhere, since there are cases where maintaining the exact characters
> entered in the textbox (for type=text) is crucial;

That's sort of my point - I don't think we want it by default for numeric either. Our intent is an input type that is for largely numeric data and is preserved as a string.
================================================================================
 #23  Jonas Sicking                                   2011-06-09 17:25:33 +0000 
--------------------------------------------------------------------------------
For the use cases you mentioned, why wouldn't you want to do it? It seems like it would be a help for people in locales that use non-latin digits.
================================================================================
 #24  Adrian Bateman [MSFT]                           2011-06-09 17:29:42 +0000 
--------------------------------------------------------------------------------
I want to make it convenient to enter a string consisting of numbers. After that I want the string as entered. In a locale where the numeric string is used with the original characters (say in part of an address) converting to 0-9 wouldn't be helpful to me.
================================================================================
 #25  Jonas Sicking                                   2011-06-09 17:33:05 +0000 
--------------------------------------------------------------------------------
This doesn't answer *why* you want that behavior? What problems would there be if numbers were consistently transformed?
================================================================================
 #26  Adrian Bateman [MSFT]                           2011-06-09 17:39:56 +0000 
--------------------------------------------------------------------------------
Because my code that says streetNumber + " " + streetName will now not give me what the user typed in and expects to see in their address but instead a partly transformed string.
================================================================================
 #27  Jonas Sicking                                   2011-06-09 18:00:14 +0000 
--------------------------------------------------------------------------------
Hmm.. well, if all you really want is a different keyboard, but otherwise the exact semantics of <input type=number>, then I agree with the comments that suggest a specific keyboard-hint attribute.
================================================================================
 #28  Simon Pieters                                   2011-06-09 20:02:04 +0000 
--------------------------------------------------------------------------------
WF2 had http://www.whatwg.org/specs/web-forms/current-work/#inputmode
================================================================================
 #29  Mounir Lamouri                                  2011-06-10 14:31:34 +0000 
--------------------------------------------------------------------------------
That seems to be an interesting feature. Why didn't it make to HTML5 Forms?
================================================================================
 #30  Simon Pieters                                   2011-06-10 18:03:17 +0000 
--------------------------------------------------------------------------------
Lack of implementation and use cases, IIRC.
================================================================================
 #31  Aryeh Gregor                                    2011-06-16 18:13:01 +0000 
--------------------------------------------------------------------------------
This is closely related to bug 12409 (filed by Apple).  We could have separate numeric and autocapitalize functions, but it makes more sense to me to combine them.  In that case, we could satisfy this bug by standardizing autocapitalize with the values that iOS already supports ("none", "sentences", "words", "characters") and add a new "numeric" value.  autocapitalize would then be a poor name for the attribute, but it makes more sense to pave the cowpaths than to introduce a new attribute or type that serves a similar purpose, IMO.
================================================================================
 #32  Tab Atkins Jr.                                  2011-06-16 21:10:41 +0000 
--------------------------------------------------------------------------------
<input type=text autocapitalize=numeric> is sufficiently wtf-y that I don't consider the reuse of similar functionality to be worthwhile.
================================================================================
 #33  Ian 'Hixie' Hickson                             2011-06-16 22:47:30 +0000 
--------------------------------------------------------------------------------
This and bug 12409 are really asking for something like the old XForms-derived inputmode="" feature (though hopefully much simpler).
================================================================================
 #34  Axel                                            2011-06-21 09:36:14 +0000 
--------------------------------------------------------------------------------
I really Like the idea of a new type for numerical input, but I think just a pattern attribute is not enough. Not all developers are regex experts (me included). Allowing a min max attribute beside of pattern would make form validation easier especially for zip codes.
================================================================================
 #36  Ian 'Hixie' Hickson                             2011-08-12 22:59:01 +0000 
--------------------------------------------------------------------------------
How urgent is this? Is this something that browsers are intending to implement before the rest of the new form features, or can it wait a few months?

We should probably summarise use cases and show screenshots of existing keyboard solutions, so that we can make sure the feature is well-designed. I've set up this wiki page for the purpose:
   http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control

From what I could tell based on the XForms equivalent feature, non-US keyboards have even more of these modes than US keyboards. So help documenting the kinds of things that might be possible wanted would be very welcome.
================================================================================
 #37  Mounir Lamouri                                  2011-09-21 21:10:18 +0000 
--------------------------------------------------------------------------------
It's not super urgent but I think it would be nice to try to specify this soon. I think browsers should be interested to implement that because it would significantly increase experience for mobile users at a very low cost: mobile browsers already know how to interact with the virtual keyboard. In addition, Apple has some non-standard way to disable/enable correction and auto-capitalization. That should be a sign browser vendors want this. That should also urge us to have a standard around those non-perfect [1] and non-standardized features.

[1] Those are boolean features were the 'on' value is the default behavior some most of the time, authors will want to write "attribute='off'". Should be 'noAttribute' instead.
================================================================================
 #38  Ian 'Hixie' Hickson                             2011-09-28 23:21:20 +0000 
--------------------------------------------------------------------------------
I strongly encourage those interested in this bug to help fill out this wiki page:
http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control
================================================================================
 #39  Michael[tm] Smith                               2011-11-20 12:28:48 +0000 
--------------------------------------------------------------------------------
I note that none of the commenters here other than Hixie ha yet actually taken time to add any content to that page. Is that because nobody has any information to contribute toward this? Or just because it's not enough of a priority for anybody to put time into providing the needed info?
================================================================================
 #40  Ian 'Hixie' Hickson                             2011-11-23 21:48:12 +0000 
--------------------------------------------------------------------------------
(I'm not closing this NEEDSINFO because if nobody else does the research, I eventually will.)
================================================================================
 #41  fantasai                                        2012-02-13 21:47:42 +0000 
--------------------------------------------------------------------------------
Just as a note, there's a non-standard 'ime-mode' property from MSIE that's related to this:
  https://developer.mozilla.org/en/CSS/ime-mode
It probably belongs more in HTML than in CSS.
================================================================================
 #42  Kang-Hao (Kenny) Lu                             2012-02-13 22:09:28 +0000 
--------------------------------------------------------------------------------
When you call it non-standard, it's actually in the css3-ui draft[1], although mysteriously enough there's never any discussion[2] about this property. In that sense, this property is indeed non-standard.

I suspect that we won't be able to remove ime-mode for backward compatibility so how this new feature interacts with ime-mode would need to be specified.

[1] http://dev.w3.org/csswg/css3-ui/#ime-mode
[2] http://www.w3.org/Search/Mail/Public/search?keywords=ime-mode
================================================================================
 #43  fantasai                                        2012-02-19 10:36:42 +0000 
--------------------------------------------------------------------------------
Looks like Tantek added it, on account of the implementations existing. Note it wasn't in the CR: http://www.w3.org/TR/2004/CR-css3-ui-20040511/
================================================================================