[whatwg] inputmode feedback

[Ian Hickson]

On Mon, 3 Feb 2014, Michael[tm] Smith wrote:
> Ian Hickson <ian at hixie.ch>, 2014-01-22 00:54 +0000:
> > 
> > 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?
> 
> I personally think it's not wrong. Well, mostly not wrong, at least (see 
> below for what I think is one specific, fixable problem.) But I believe 
> one objection that others have made to the current set of modes is that 
> for Latin input it provides values that conflate typing-aids hints with 
> the script hint, while for Japanese input, it does not.

Well, nobody has suggested that there are any typing aid hints applicable 
to Japanese input yet. The current list for Japanese (and all non-Latin- 
script languages) are just the list of input modes people told me were 
needed (since nobody has asked for anything for anything but Japanese and 
Latin-script languages, there's nothing for those).


> That means there's at least one possibly-useful mode that inputmode 
> currently does make expressible: a "name" mode for kana input (to 
> correspond to the latin-name mode).

Added.


> What I mean is, what value would an author choose if they wanted to 
> indicate a mode for inserting human-readable kana-input human names?

As of now, "kana-name".


> Asking that question makes me realize that we probably don't actually 
> want a "-name" mode for the contact-list case anyway -- because a 
> Japanese user is likely to have a contact list that contains names both 
> in Kanji and in Latin characters. So if we really want to provide "text 
> prediction from the user's contact list", I think we'd probably want to 
> just add an script-less inputmode=contact value for that.

If there was going to be a "keyboard" that consisted primarily of a 
contact list, I'd agree. But the keyboard will be a keyboard, and it'll 
autocomplete from a contact list. And thus that keyboard needs a default 
mode to be in. If all my friends have Latin-script names, it is 
inconvenient if the keyboard starts with a Russian keyboard. I presume, 
based on what you suggested above, that a Japanese user would find it more 
helpful if their keyboard started in a mode for "kana or romaji input, 
typically hiragana input".


> Also, there are things other than human names for which namecase (aka 
> titlecase) is useful: For example, a field where the user is expected to 
> type in a book title or movie title. For those kinds of fields, you 
> clearly wouldn't want "text prediction from the user's contact list" 
> turned on also. Instead you'd just want it to be inputmode=titlecase.

If users actually want auto-title-casing, then yes, we could introduce a 
"latin-title-case" mode, or something like that. Do they? I haven't heard 
of a request for this so far.


> Anyway, I think the root problem might be that we have 
> inputmode=latin-name to begin with.

I don't understand why it's a problem.


> So I'd suggest either dropping it entirely, or replacing it with the two 
> new values inputmode=titlecase and inputmode=contact.

That wouldn't give the UA the information the UA needs to pick the right 
keyboard.


> And as far as using inputmode for specifying typing aids instead of just 
> script, I don't what other kinds of typing aids (other than the contact 
> case) would be relevant for Japanese input. The main typing aids the 
> spec mentions are autocapitalization, autocorrect, and text prediction. 
> Among those, capitalization isn't relevant for Japanese input at all. 
> And as far as autocorrect, in my experience at least, autocorrect isn't 
> a feature that's commonly used anywhere with IMEs for Japanese input, so 
> it's not relevant. And as far as text prediction, in Japanese IMEs text 
> prediction is always turned on anyway, and I can't think of cases where 
> a user would really care to have it turned off (or be bothered by having 
> it on).

Right, each script has different needs. That's why these are not 
orthogonal concerns; they're input modalities.

I don't know anything about what input modalities are needed outside of 
Latin script keyboards, so I rely on people reporting what is missing so 
that I can add it.


> Come to think of it, in soft keyboards on smartphones for Latin input too,
> text prediction is always on anyway.

Not always. For example, you wouldn't want to have it on in a password 
field or URL field.


> So maybe these days there's not much of a real need to provide a hint 
> for a "text prediction on" typing aid -- because "text prediction on" is 
> the default anyway. Maybe instead there's now more of a need for a "text 
> prediction off" typing aid, I dunno.

The spec doesn't have a default mode and an "on" mode (or "off" mode), it 
just has various different modes, some with and some without certain 
features (or rather, hints as to whether those features should be there or 
not by default).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'