Intent to Implement “inputmode”
Kenji Baheux
Primary eng/PM emails
Eng: yoi...@chromium.org, ko...@chromium.org PM: kenji...@chromium.org
Spec
http://www.w3.org/html/wg/drafts/html/master/forms.html#input-modalities:-the-inputmode-attribute
Summary
The inputmode content attribute is an enumerated attribute that specifies what kind of input mechanism would be most helpful for users entering content into the text form control.
Motivation
This attribute helps setting the default input modality as a hint, so users can save some operation to change the mode manually or indicate the behavior of the input field against typed characters, e.g. for “varbatim”, any spelling correction or typing suggestion should be disabled.
Compatibility Risk
The spec is still being discussed. Currently, IE10 appears to have some implementation (see demo at http://olav.dk/wf2/demo/inputmode.asp). Firefox implemented it as x-inputmode due to some incompatibilities with the latest spec. However, the behind the flag implementation can adapt as the spec evolves.
Ongoing technical constraints
As some of the mode (“katakana” for example) may not be selected using the APIs provided by system (on Linux, for example), fallback mode in the spec should be refined.
Will this feature be supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?
Yes. Some of the modes may not be available on some platform, but as the spec says “User agents must recognise all the keywords and corresponding states given below, but need not support all of the corresponding states. If a keyword's state is not supported, the user agent must act as if the keyword instead mapped to the given state's fallback state,” it is not an issue here.
OWP launch tracking bug?
Row on feature dashboard?
Yes.
Requesting approval to ship?
No.
TAMURA, Kent
TAMURA Kent
Software Engineer, Google
Mounir Lamouri
Mozilla expressed some concerns regarding the current value set the
specification lists. On Firefox Android we implemented something
different and on Firefox OS, we implemented something yet different
(sic). I was wondering if you guys are planning to implement the exact
list Hixie spec'd or are you thinking of implementing something else?
Thanks,
--
Mounir
On 12/06/13 08:27, Kenji Baheux wrote:
> Primary eng/PM emails
>
> ko...@chromium.org <mailto:ko...@chromium.org>PM:
> kenji...@chromium.org <mailto:kenji...@chromium.org>
>
>
> Spec
>
> http://www.w3.org/html/wg/drafts/html/master/forms.html#input-modalities:-the-inputmode-attribute
>
>
> Summary
>
> The inputmode content attribute is an enumerated attribute that
> specifies what kind of input mechanism would be most helpful for users
> entering content into the text form control.
>
>
> Motivation
>
> This attribute helps setting the default input modality as a hint, so
> users can save some operation to change the mode manually or indicate
> the behavior of the input field against typed characters, e.g. for
> “varbatim”, any spelling correction or typing suggestion should be disabled.
>
>
> Compatibility Risk
>
> The spec is still being discussed. Currently, IE10 appears to have some
> implementation (see demo at http://olav.dk/wf2/demo/inputmode.asp).
> Firefox implemented it as x-inputmode
> flag implementation can adapt as the spec evolves.
>
>
> Ongoing technical constraints
>
> As some of the mode (“katakana” for example) may not be selected using
> the APIs provided by system (on Linux, for example), fallback mode in
> the spec should be refined.
>
>
> Will this feature be supported on all five Blink platforms (Windows,
> Mac, Linux, Chrome OS and Android)?
>
> Yes. Some of the modes may not be available on some platform, but as
> the spec says “User agents must recognise all the keywords and
> corresponding states given below, but need not support all of the
> corresponding states. If a keyword's state is not supported, the user
> agent must act as if the keyword instead mapped to the given state's
> fallback state,” it is not an issue here.
>
>
> OWP launch tracking bug?
>
Takayoshi Kochi
Takayoshi Kochi
Mounir Lamouri
Mozilla's current situation regarding 'inputmode' is summarised here:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-February/038914.html
(tl;dr: "To conclude, Mozilla is interested in implementing this set of
keywords: verbatim, text, name, prose and digit (or numeric).")
We - Mozilla - are more than happy to have more people involved on that
API and if Google and Microsoft believe that they have a good solution,
we will gladly follow. However, I would be concerned if we have to
implement something simply because Microsoft did it and not for the
technical qualities of the solution.
--
Mounir
On 21/06/13 05:34, Takayoshi Kochi wrote:
> Hi Mounir,
>
> We are starting off of the current HTML spec, but as IE10 looks like its own
> implementation and we are concerned about interoperability.
>
> While implementing we are also checking feasibility of the modes in various
> platform and we'd like to contribute to the standard spec.
>
> Is Firefox's implementation summarized here as a proposal?
> http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control
>
>
>
> On Fri, Jun 21, 2013 at 12:42 AM, Mounir Lamouri <mou...@lamouri.fr
> <mailto:mou...@lamouri.fr>> wrote:
>
> Hi Kenji,
>
> Mozilla expressed some concerns regarding the current value set the
> specification lists. On Firefox Android we implemented something
> different and on Firefox OS, we implemented something yet different
> (sic). I was wondering if you guys are planning to implement the exact
> list Hixie spec'd or are you thinking of implementing something else?
>
> Thanks,
> --
> Mounir
>
> On 12/06/13 08:27, Kenji Baheux wrote:
> > Primary eng/PM emails
> >
> <mailto:yoi...@chromium.org <mailto:yoi...@chromium.org>>,
> > ko...@chromium.org <mailto:ko...@chromium.org>
> <mailto:ko...@chromium.org <mailto:ko...@chromium.org>>PM:
> > kenji...@chromium.org <mailto:kenji...@chromium.org>
> <mailto:kenji...@chromium.org <mailto:kenji...@chromium.org>>
