[whatwg] inputmode feedback

[Takayoshi Kochi (河内 隆仁)]

Hi Ian,

On Wed, Jan 22, 2014 at 9:54 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 6 Dec 2013, Yoichi Osato wrote:
> >
> > Our Google Japan members working around IME discussed about inputmode.
> >
> > Proposal:
> > Remove "kana", "katakana" and "full-width-latin" from inputmode
> attribute.
> > Because above attributes and others are independent as others say.
>
> I don't really understand. What is independent?
>

As you noted below, "kana" "katakana" "full-width-latin" are low-level mode
details of
specific language (Japanese) input method.

Probably we can move these 3 modes from inputmode and make such low-level
mode
change available under IME API (http://www.w3.org/TR/ime-api/).

The idea of the inputmode="" attribute is that it gives the mode that is
> most likely to be needed by the user when providing input. There's various
> modes that seem to make sense:
>
>  - inserting raw latin-script characters, like passwords, product codes
>
>  - inserting human-readable latin-script short-form text, like search
>    queries
>
>  - inserting human-readable latin-script human names
>
>  - inserting human-readable latin-script long-form text, like blog posts
>
>  - inserting numeric data, like credit card numbers
>
>  - inserting text in other scripts, of which I know nothing
>
>  - inserting human-readable latin-script text within long-form text in
>    other scripts
>
> You don't use the same kind of keyboard for inserting raw latin-script
> characters as for inserting Japanese long-form prose, so it makes sense to
> me that they'd use different input modes.
>
> Why is this wrong?


Usually such traits for an input field persists statically, while the modes
above
are dynamic one and have to explicitly modify the state of system IME.

> For web developers that want to manage IME state like native
> > applications, the inputmode attribute lacks some modes like
> > "half-width-katakana". But it might cause more confusing to add such
> > attributes to inputmode.
>
> I'm not sure exactly what you mean by "manage IME state like native
> applications". Can you elaborate? Do you mean provide custom IMEs? Do you
> mean have low-level control over the specific keyboard or other input
> facilities provided by the OS?
>

Japanese IME (e.g. Microsoft IME) has several modes for typing characters,
divided by the category of the set of characters (kana, half-width-kana,
alphanumeric,
full-width-latin etc.), each of which has different purpose for
representing things
(e.g. imported words or computer programs are written in alphabets, while
other Japanese
text is written in kana and kanji, converted from kana using IME) and
switching
these submodes are critical part of (at least desktop) IMEs to efficiently
type
text with several of these sets of characters with alphabet-only physical
keyboard.
These modes are actually sub-modes of a specific language (Japanese) IME.

Take a look at a Japanese blog post e.g.
http://googlejapan.blogspot.jp/2014/01/google-chrome.html
You can see alphabets, numbers and other Japanese characters (hiragana,
katakana, kanji)
are all used in one entry.

Native windows applications of course have control over such modes per
input focus,
and Flash (ActionScript) has similar functionality.
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/IME.html#conversionMode
(I'm not familiar with Korean/Chinese, but from the Flash spec above, they
only have
IME on or off, they don't have sub-modes like Japanese - please correct me
if I'm wrong).

So for completing the feature parity for Japanese web users against native
applications,
these modes has importance but we think inputmode is not an appropriate
place to put it on.

For one thing, such Japanese IME submodes are dynamic by nature (user can
move from one to another
with some key combinations or via IME menu).
When user move focus from one field to another, the submode is persistent.

E.g. You have a form:

Zip: []   <- alphanumeric
Address: [] <- kanji (kana)
Building: [] <- kanji (kana), and maybe numeric for building/room number
etc.
Name: [] <- kanji (kana)
Tel: [] <- number

Without any inputmode or alike, you start from zip code, you turn off IME
(if it's on) and type in zip code,
then press tab to the next field, IME is still off, you turn on IME to fill
address, type in building and name.
At the Tel field, you have to turn off IME (or change IME submode to
"half-width-latin") manually, because
the IME submode (at this point, most probably in "kana" mode) persists.

If "inputmode" has these Japanese IME submodes (it does), users can save
switching modes manually when
hopping from one field to another.
Usually Japanese users are accustomed to changing these modes manually, so
if the mode changes
automatically, it may cause a surprise, but use cases such as inputting a
lot of entries for address book
repetitively, it would save the mode switching much.

That said, though inputmode is useful to declaratively write the "default"
expected submode for the field to be
initially in, once user manually change the mode from the initial submode,
it is not apparent
how should the browser behave when user re-focus that field?
Browser implementer can have several choices here:

1. Change the IME mode to what is specified as "inputmode".
2. Remember the last mode when the focus was there and restore the mode.
3. Do nothing, if the mode of the field manually changed to something else.
4. none of the above(?)

The current inputmode spec doesn't say anything about this detail, and what
is the best choice
can be different case-by-case.

Also, inputmode is modifiable from Javascript code, e.g. element.inputmode
= "kana" while
user is typing something with IME - which can be a disruptive operation.
This is also another reason that such Japanese IME submodes have better
affinity to IME API
than HTML inputmode.

The idea here is to provide no low-level control, but to give high-level
> hints to the browser, as with everything else in HTML. This is how we
> achieve device- and platform-independence.
>
>
> > We are discussing to propose IME mode management as new API. Its mode
> > contains "alphabet, kana, katakana, full-width-latin,
> > harf-width-katakana" as a native OS provides.
>
> This seems like a lower-level feature than what inputmode="" is intended
> to provide.


Yes.


>
> On Fri, 6 Dec 2013, Michael[tm] Smith wrote:
> >
> > [Maybe we should take this discussion off-list or talk about it some
> > time soon over lunch or something. For now though, here are some
> > comments.]
>
> I very much encourage people to discuss this on this list, as that is a
> great way for me (and others) to learn about this stuff. :-)
>
>
Indeed.

 On Mon, 9 Dec 2013, Takayoshi Kochi (河内 隆仁) wrote:
> >
> > Probably the reason some Japanese banks still use half-width kana is
> > what Ryosuke said, but as Mike saw in Mizuho and Mitsui Sumitomo, they
> > are moving away from forcing user to type in half-width kana directly,
> > they convert on server side - I think this is a good trend.
> >
> > Aside from banking, I guess there are still people who *want* to type in
> > Japanese in half-width kana, e.g. "キター" can implicitly add some
> > nuances against "キター".
> >
> > My position is that we allow end-users to type-in whatever they want,
> > but server side people should try to accept users' input as widely as
> > possible and validate or normalize themselves.
>
> inputmode="" isn't intended to prevent specific input modes from being
> selected by the user. Are there use cases that we want to support for
> explicitly selecting half-width kana? I'm happy to add it if it is
> helpful. The discussion seemed to suggest we should encourage UAs not to
> support it; if that's what we want to do, I don't think we should spec it.
>
>
> > The point that Yoichi wanted to make was to extract IME-related part of
> > 'intputmode' spec and move out of inputmode, or at least separate the
> > discussion about IME-related modes and other modes, otherwise the
> > discussion will never go anywhere.
>
> I'm not sure I understand what you consider IME-related and what is not.
> Can you elaborate on this?
>
>
Does the explanation above work for you?
If anything is unclear, I'm happy to elaborate more.

 > How about using this bug as a starting point of the discussion (although
> > it's on w3c bugzilla)?
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=23961
>
> That's a bug on the W3C HTML5 spec, so it isn't one that I'm tracking. I
> encourage you to post on this list or to file a new bug if you prefer to
> discuss things on a bug system: http://whatwg.org/newbug (it also uses
> the W3C Bugzilla, but a different component)
>
>
Hmm, then does changing the "Product" from "HTML WG" to "WHATWG" work?
(I'm not changing myself anyway - would like to defer this to Ben Bucksh.)


> > Ben Bucksh (cc'ed) pointed out in the bug entry that inputmode has at
> > least 3 aspects (script/language, data type, typing aid).  There is room
> > for discussion whether we should split inputmode into every orthogonal
> > modes, but whether we split or not, we would like to separate discussion
> > whether each mode is good or not into these categories.
>
> The inputmode="" attribute only has one aspect: what does the user want to
> enter. This can impact many things, including the script, the language,
> the kinds of keys that are visible, the kinds of typing aids enabled, the
> source(s) of autocomplete data, and so on. There are many different
> platforms that can use inputmode="": a mobile visual device might use an
> on-screen keyboard or on-screen handwriting recognition widget, a desktop
> computer might use a fully-fleged IME system, a speech-based system might
> do everything using speech recognition and use the input mode to decide
> what dictionaries to use for recognition and what scripts to use for
> transcribing the results.
>
> Exposing all these aspects to the author is a losing proposition: authors
> would frequently make mistakes, forget certain classes of users or
> devices, fail to test on all possible platforms, etc. The solution is to
> use the high-level semantic approach used elsewhere by HTML, and thus just
> provide a high-level description of the kind of input that is expected,
> letting the user agent translate this into the appropriate settings for
> the OS-level input system.
>
>
Well, then you seem to support that such Japanese IME submodes are low-level
and should not belong to inputmode :)


>
> On Mon, 16 Dec 2013, Michael[tm] Smith wrote:
> >
> > As I commented in bug 23961, the value of the inputmode attribute was
> > originally specified as taking a list of tokens, where one token is
> > optionally the name of a script like "latin" and the rest of the tokens
> > were optional modifiers.
> >
> > So you could imagine a value like inputmode="latin titlecase
> > prediction".
> >
> > I'm not saying I think the use cases actually merit changing the
> > inputmode microsyntax to be a list of tokens like that. But it might be
> > preferable to introducing yet more attributes.
>
> We originally had this in Wbe Forms 2.0, but it is far more complex than
> necessary, IMHO. Authors don't need that level of control in the vast
> majority of cases.
>
> --
> Ian Hickson               U+1047E                )¥._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. ¥   _¥  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>


-- 
Takayoshi Kochi