This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 12885 - WF3: Provide a way for the author to specify what kind of keyboard behaviour to use for text inputs on multimodal keyboards (e.g. show the numeric keyboard, capitalise the first character by default, etc)
Summary: WF3: Provide a way for the author to specify what kind of keyboard behaviour ...
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P3 enhancement
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: a11y, a11ytf
Depends on:
Blocks: 12409
  Show dependency treegraph
 
Reported: 2011-06-03 22:28 UTC by Adrian Bateman [MSFT]
Modified: 2013-02-01 23:58 UTC (History)
27 users (show)

See Also:


Attachments

Description Adrian Bateman [MSFT] 2011-06-03 22:28:37 UTC
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.
Comment 1 Jonas Sicking (Not reading bugmail) 2011-06-03 22:52:38 UTC
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.
Comment 2 Tab Atkins Jr. 2011-06-04 00:14:59 UTC
I like the idea, with the same naming concern as Jonas.  Maybe type="digits"?
Comment 3 Jonas Sicking (Not reading bugmail) 2011-06-04 00:25:15 UTC
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.
Comment 4 Paul Cotton 2011-06-04 16:12:08 UTC
>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
Comment 5 Henri Sivonen 2011-06-04 16:53:17 UTC
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
Comment 6 Aryeh Gregor 2011-06-05 19:26:11 UTC
(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.
Comment 7 Adrian Bateman [MSFT] 2011-06-06 16:45:28 UTC
(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.
Comment 8 Aryeh Gregor 2011-06-06 19:12:42 UTC
(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.
Comment 9 Ehsan Akhgari [:ehsan] 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.
Comment 10 Jonas Sicking (Not reading bugmail) 2011-06-07 02:52:30 UTC
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.
Comment 11 Henri Sivonen 2011-06-07 05:43:52 UTC
(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.
Comment 12 Jonas Sicking (Not reading bugmail) 2011-06-07 08:15:01 UTC
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?
Comment 13 Adrian Bateman [MSFT] 2011-06-07 16:50:54 UTC
(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.
Comment 14 Ehsan Akhgari [:ehsan] 2011-06-07 17:17:15 UTC
(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...
Comment 15 Adrian Bateman [MSFT] 2011-06-07 17:20:47 UTC
(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.
Comment 16 Jonas Sicking (Not reading bugmail) 2011-06-07 19:35:14 UTC
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.
Comment 17 Ehsan Akhgari [:ehsan] 2011-06-07 20:15:57 UTC
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.
Comment 18 Henri Sivonen 2011-06-08 05:05:01 UTC
(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.
Comment 19 Volker Krebs 2011-06-08 09:58:50 UTC
(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
Comment 20 Jonas Sicking (Not reading bugmail) 2011-06-08 12:41:22 UTC
(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).
Comment 21 Ehsan Akhgari [:ehsan] 2011-06-08 17:59:23 UTC
To avoid confusion, I've filed bug 12915 to request <input type=number> to accept Arabic and Persian digits.
Comment 22 Adrian Bateman [MSFT] 2011-06-09 14:50:54 UTC
(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.
Comment 23 Jonas Sicking (Not reading bugmail) 2011-06-09 17:25:33 UTC
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.
Comment 24 Adrian Bateman [MSFT] 2011-06-09 17:29:42 UTC
(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.
Comment 25 Jonas Sicking (Not reading bugmail) 2011-06-09 17:33:05 UTC
This doesn't answer *why* you want that behavior? What problems would there be if numbers were consistently transformed?
Comment 26 Adrian Bateman [MSFT] 2011-06-09 17:39:56 UTC
(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.
Comment 27 Jonas Sicking (Not reading bugmail) 2011-06-09 18:00:14 UTC
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.
Comment 28 Simon Pieters 2011-06-09 20:02:04 UTC
WF2 had http://www.whatwg.org/specs/web-forms/current-work/#inputmode
Comment 29 Mounir Lamouri 2011-06-10 14:31:34 UTC
(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?
Comment 30 Simon Pieters 2011-06-10 18:03:17 UTC
Lack of implementation and use cases, IIRC.
Comment 31 Aryeh Gregor 2011-06-16 18:13:01 UTC
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.
Comment 32 Tab Atkins Jr. 2011-06-16 21:10:41 UTC
(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.
Comment 33 Ian 'Hixie' Hickson 2011-06-16 22:47:30 UTC
This and bug 12409 are really asking for something like the old XForms-derived inputmode="" feature (though hopefully much simpler).
Comment 34 Axel 2011-06-21 09:36:14 UTC
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.
Comment 35 Michael[tm] Smith 2011-08-04 05:12:22 UTC
mass-move component to LC1
Comment 36 Ian 'Hixie' Hickson 2011-08-12 22:59:01 UTC
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.
Comment 37 Mounir Lamouri 2011-09-21 21:10:18 UTC
(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.
Comment 38 Ian 'Hixie' Hickson 2011-09-28 23:21:20 UTC
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
Comment 39 Michael[tm] Smith 2011-11-20 12:28:48 UTC
(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?
Comment 40 Ian 'Hixie' Hickson 2011-11-23 21:48:12 UTC
(I'm not closing this NEEDSINFO because if nobody else does the research, I eventually will.)
Comment 41 fantasai 2012-02-13 21:47:42 UTC
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.
Comment 42 Kang-Hao (Kenny) Lu 2012-02-13 22:09:28 UTC
(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
Comment 43 fantasai 2012-02-19 10:36:42 UTC
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/
Comment 44 contributor 2012-07-18 15:59:38 UTC
This bug was cloned to create bug 18030 as part of operation convergence.
Comment 45 brunoais 2012-07-21 08:21:05 UTC
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.
Comment 46 Silvia Pfeiffer 2012-09-28 08:24:43 UTC
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
Comment 47 Robin Berjon 2012-10-01 12:00:04 UTC
(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.
Comment 48 Charles McCathieNevile 2012-10-05 10:35:47 UTC
(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...)
Comment 49 Edward O'Connor 2012-10-16 17:28:50 UTC
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.
Comment 50 Robin Berjon 2012-10-22 10:35:51 UTC
(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.
Comment 51 Robin Berjon 2013-01-21 15:58:58 UTC
Mass move to "HTML WG"
Comment 52 Robin Berjon 2013-01-21 16:01:43 UTC
Mass move to "HTML WG"
Comment 53 Travis Leithead [MSFT] 2013-02-01 23:58:41 UTC
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")