W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2013

Re: [whatwg] inputmode feedback

From: (wrong string) 河内 隆仁 <kochi@google.com>
Date: Fri, 15 Feb 2013 17:28:03 +0900
Message-ID: <CADP2=hp-yPwWAKpeuPUwaAF=LmMfyC0Uw2_KxgQGY7cr3GaKuA@mail.gmail.com>
To: Mounir Lamouri <mounir@lamouri.fr>
Cc: whatwg@lists.whatwg.org
Hello Mounir,

On Thu, Feb 14, 2013 at 4:29 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:

> Regarding the three Japanese specific types, it is not clear if
> inputmode is the best way to solve the use cases intended to be solved.
> Actually, 'kana' and 'katakana' are trying to give a hint about the
> script that has to be used which seems to be orthogonal with the other
> types. We could allow inputmode to have a set of values but that would
> make the behaviour way more complex so I wonder if we couldn't try to
> solve that problem with another attribute like inputscript.
"three Japanese specific types"? 'kana', 'katakana', and 'full-width-latin"?

I agree that it is weird 'kana' and 'katakana' are listed as inputmode
and 'inputscript' sounds more reasonable place where they should be listed.

As you probably know, there is also 'ime-mode' CSS style which IE/FF
(and still proposed in CSS3 UI at http://www.w3.org/TR/css3-ui/#ime-mode),
which makes this more complex to use.

People may want to control IME input mode like the way Flash can,
but it it is unfortunate that controlling IME from web apps is so
distributed (CSS, input attribute,
DOM lv3 compositionevent and IME API).

That said, even though authors of web apps may want to force the IME mode or
its script mode for user's sake, it may cause user's confusion as they are
so accustomed to change mode manually where such mode is required.
So if a web app sets some mode, the user may toggle it back to unintended
and get frustrated.

Takayoshi Kochi
Received on Friday, 15 February 2013 08:28:48 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:19 UTC