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.

I like the idea, with the same naming concern as Jonas.  Maybe type="digits"?

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.

>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

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

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

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

(In reply to comment #7)
> 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.

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.

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

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.

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

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?

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

(In reply to comment #13)
> (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.

I can't see why having free-form digit input would mean that we shouldn't perform special handling for Arabic and Persian digits...

(In reply to comment #14)
> (In reply to comment #13)
> > (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.
> 
> I can't see why having free-form digit input would mean that we shouldn't
> perform special handling for Arabic and Persian digits...

Why not always do that then? This could happen for type=text too and so doesn't need to be influenced by the type.

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.

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.

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

(In reply to comment #18)
> (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.

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

(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).

To avoid confusion, I've filed bug 12915 to request <input type=number> to accept Arabic and Persian digits.

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

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.

(In reply to comment #23)
> 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.

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.

This doesn't answer *why* you want that behavior? What problems would there be if numbers were consistently transformed?

(In reply to comment #25)
> This doesn't answer *why* you want that behavior? What problems would there be
> if numbers were consistently transformed?

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.

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.

WF2 had http://www.whatwg.org/specs/web-forms/current-work/#inputmode

(In reply to comment #28)
> WF2 had http://www.whatwg.org/specs/web-forms/current-work/#inputmode

That seems to be an interesting feature. Why didn't it make to HTML5 Forms?

Lack of implementation and use cases, IIRC.

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.

(In reply to comment #31)
> 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.

<input type=text autocapitalize=numeric> is sufficiently wtf-y that I don't consider the reuse of similar functionality to be worthwhile.

This and bug 12409 are really asking for something like the old XForms-derived inputmode="" feature (though hopefully much simpler).

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.

mass-move component to LC1

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.

(In reply to comment #36)
> 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?

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.

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

(In reply to comment #38)
> 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

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?

(I'm not closing this NEEDSINFO because if nobody else does the research, I eventually will.)

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.

(In reply to comment #41)
> 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.

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

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/

This bug was cloned to create bug 18030 as part of operation convergence.

I checked the wiki (http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control).
For both proposals, I prefer the way of thinking of Ian Hickson even though the gecko proposed one is not bad at all.

Is this a feature that we want to see in the HTML5 spec or something for HTML.next?

I have the changes parked in a feature branch for now, see 

https://github.com/w3c/html/compare/master...feature;whatwg_inputmode

(In reply to comment #46)
> Is this a feature that we want to see in the HTML5 spec or something for
> HTML.next?
> 
> I have the changes parked in a feature branch for now, see 
> 
> https://github.com/w3c/html/compare/master...feature;whatwg_inputmode

Maybe preflight that with implementers and the group in general, but if it's at all possible to merge this feature in for 5.0 then we definitely should take it.

(In reply to comment #47)
> (In reply to comment #46)
> > Is this a feature that we want to see in the HTML5 spec or something for
> > HTML.next?
> > 
> > I have the changes parked in a feature branch for now, see 
> > 
> > https://github.com/w3c/html/compare/master...feature;whatwg_inputmode
> 
> Maybe preflight that with implementers and the group in general, but if it's at
> all possible to merge this feature in for 5.0 then we definitely should take
> it.

If implementors are keen it probably makes sense to restore it to 5.0 (inputmode was a feature of WML that ended up in XHTML 1.2 IIRC so there are some people who have implemented it before).

Isn't the approved way of doing this to write an extension spec? (On the plus side, once you have a template for those it takes about 25 minutes...)

Assigning to Robin as he believes we should get this in for HTML5.

Robin, there are other bugs (some in the HTML.next component) related to inputmode=""; if you do address this one in the HTML5 timeframe, you might be able to kill several birds with one stone.

(In reply to comment #49)
> Assigning to Robin as he believes we should get this in for HTML5.

I would love to get this for HTML5 but we currently have implementations that differ from the spec and may continue to do so, so I wouldn't rate this as stable enough for inclusion just yet.

Mass move to "HTML WG"

Mass move to "HTML WG"

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:


   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: Already included in the 5.1 spec.
Rationale: Please see current 5.1 spec section:
http://www.w3.org/html/wg/drafts/html/master/single-page.html#attr-fe-inputmode

(inputmode attributes of input element, with value "numeric")