[whatwg] inputmode feedback

[Ian Hickson]

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?


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?


> 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?

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.


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. :-)


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?


> 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)


> 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.


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.   `._.-(,_..'--(,_..'`-.;.'