Add the inputmode attribute to HTMLInputElement and HTMLTextAreaElement DOM interfaces

• Component: Forms
• Status: RESOLVED DUPLICATE

[Dominique Hazael-Massieux]

XHTML MP 1.2 and XHTML Basic 1.1 provide the "inputmode" attribute on <input> and <textarea>, allowing the author to indicate what kind of input is expected on those fields (e.g. numeric, or uppercase).
http://www.w3.org/TR/2007/CR-xhtml-basic-20070713/#s_inputmode

It is particularly useful on mobile devices, where the limited keyboard makes these indications a great hint to active either the numeric input or the alphabetical mode.

I believe the WAP equivalent (based on CSS properties rather than markup) is already implemented in webkit, so implementing the markup version may re-use some of the existing code.

[Michelangelo De Simone]

This is part of WF2 spec as well, 19264 depends on this.

[sideshowbarker]

(In reply to comment #1)
> This is part of WF2 spec as well, 19264 depends on this.

Actually, inputmode was part of the WF2 spec, but the WF2 spec is now obsoleted by the Forms section of the HTML5 draft. See the following:

  http://www.whatwg.org/specs/web-forms/current-work/
  "This draft has been superseded by the Forms chapter of the HTML5 specification, which now
   includes many of the features first defined in this document."

And see the Forms section in the HTML5 draft:
  http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html

So the current status of inputmode in HTML5 is that it's not part of the language; that is, not only is it not a valid element, it's not recognized at all in the HTML5 parsing algorithm or anywhere else in the draft.

Of course that doesn't mean it can't be added to HTML5 later, if there's a compelling case for adding it. The reason it's not in there now is that when the editor did an evaluation of what parts of WF2 should be integrated into HTML5, the inputmode attribute didn't make the cut. The rationale was

  - there still do not seem to be any production browsers shipping with inputmode support
  - but there are a number of mobile browsers shipping with support for the  -wap-input-format attribute
  - because the main use-case for input-mode-switching is on mobile devices that only have keypads 
    (not full keyboards) and the -wap-input-format  attribute is already widely used by
    mobile developers/sites, those developers and sites can just keep using -wap-input-format
    and don't need the inputmode attribute
  - in discussions (admittedly, limited ones), nobody was able to articulate a clear use-case for
    inputmode other than on mobile/constrained devices (where -wap-input-format is used instead),
    so it's not clear what problem would be solved by adding inputmode support for browsers on other
    devices (e.g., on desktop browsers)

Anyway, that's where were at with it as far as HTML5 goes. Discussions about whether inputmode should be added to HTML5 should go to the W3C public-html mailing list or the WHATWG mailing list.

[Michelangelo De Simone]

Noted, thank you Michael. Perhaps we should set this to WONTFIX or INVALID for now, just to keep things clear.

Thank you.

[David Smith]

INVALIDating as requested.

[sideshowbarker]

(In reply to comment #4)
> INVALIDating as requested.

I don't know what your project policy is for moving bugs to INVALID without first asking the bug reporter for further feedback -- but for the record, neither the bug reporter nor anybody else requested that this be moved to INVALID. Michelangelo was asking, not requesting: "Perhaps we should set this to WONTFIX or INVALID for now, just to keep things clear."  And Michelangelo was not the one who reported the bug, Dom was.

I was simply noting what the current case with respect to inputmode in the HTML5 draft is. But it's not impossible that the status of inputmode could change and eventually make it into a W3C HTML5 draft. Regardless, HTML5 is not the be-and-end-all; in this case, as Dom noted, inputmode is actually part of another full W3C Recommendation, the XHTML Basic 1.1 Recommendation:

  http://www.w3.org/TR/xhtml-basic/

[Michelangelo De Simone]

I'm to blame for the mistake, David is innocent.:) Asking for reopening.

Apparently this was closed by mistake.

[sideshowbarker]

Something that could be done to add a degree of support for inputmode in WebKit itself would just be to add the inputmode attribute to the HTMLInputElement and HTMLTextAreaElement interfaces, so that inputmode could be accessed as a property on input and textarea objects.

Dominique, maybe you could retitle the summary for this bug to request that? (If you agree) Either that or maybe open a new bug with that summary.

Im suggesting that because it seems like actually implementing full support for input-mode switching is something that's platform-dependent/device-dependent. It requires the browser to understand how to interact with the input-method editor on whatever device the browser happens to be installed on, and tell the IME what mode to switch into. I would assume that kind of code would never be part of the WebKit code itself, but instead part of the browsers/platform code for a particular browser that uses WebKit.

But making inputmode accessible as a property would at least provide a basis for a browser builder to implement inputmode support on top of WebKit for a particular browser-platform-device.

[sideshowbarker]

I think this bug could now bemarked as a duplicate of bug 23588, since the proposed patch submitted against that bug pretty much does what the revised Summary description for this bug proposes.
 
https://bugs.webkit.org/attachment.cgi?id=27108&action=prettypatch

[George Staikos]

*** This bug has been marked as a duplicate of bug 23588 ***