[whatwg] inputmode feedback

[Michael[tm] Smith]

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.

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

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?

It's true there's no capitalization in Japanese names (as there is with
Latin names), so if all that the -name value indicated was namecase
autocapitalization, we wouldn't need a kana-name value.

But a UA could  use the latin-name mode for more than just turning on
namecase autocapitalization. For example, the spec notes that the mode
could trigger "text prediction from the user's contact list".

So what would an author do if they if they wanted a mode that signals both
kana input and "text prediction from the user's contact list"?

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.

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.

Anyway, I think the root problem might be that we have inputmode=latin-name
to begin with. So I'd suggest either dropping it entirely, or replacing it
with the two new values inputmode=titlecase and inputmode=contact.

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

Come to think of it, in soft keyboards on smartphones for Latin input too,
text prediction is always on anyway. 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.

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

Yeah, agreed. After thinking about it, it seems to me that we don't really
have a need for any new combinations. If we were to add anything new for
the use cases that have come up, I think it would just be a inputmode=contact
value and maybe an inputmode=titlecase value (which would just imply Latin
input, since it'd only be relevant to Latin). And drop inputmode=latin-name.

  --Mike

-- 
Michael[tm] Smith http://people.w3.org/mike