[whatwg] inputmode feedback

[Mounir Lamouri]

Hi,

Mozilla did implement an inputmode attribute for the <input> element a
few months ago and the HTML specification has been updated after that to
introduce that attribute. Given that the specification and our
implementation was not matching, we decided to delay the release of that
feature [1] and not advertise it. We unfortunately had to push a
"x-inputmode" attribute in Firefox OS because our UI needed that feature
but we expect to replace this with a proper inputmode implementation as
soon as possible.

Basically, the Mozilla's inputmode attribute is describing behaviour,
the allowed value are mostly self-explanatory: auto, uppercase,
lowercase, titlecase, autocapitalized, digit and numeric.
Autocapitalized is capitalizing words at the beginning of a sentence and
the difference between digit and numeric is whether or not there should
be a decimal separator and numeric operators available.

The attribute as specified in HTML seems to focus on use cases, it
provides more semantic and takes into account the handling of
suggestions/corrections. However, the current set of values seems overly
complex.

To begin with, I think we should get rid of the "latin" prefix. The
three modes with that prefix are "latin", "latin-name" and "latin-prose"
but in none of those situations "latin" is mandatory.
The first one could be "text": we want to have typing aid enabled and
any other feature related to entering some basic non-formatted text.
(The difference between "verbatim" and this type is weak and "text"
might not be the best way to improve this.)
The second one is simply "name": whatever the script is, we want to
enter a name in this field.
The last one is "latin-prose": like the others, the use case is to write
some formatted-text, the script shouldn't have any impact.

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.

Mozilla's implementation has 'numeric' and 'digit' and 'numeric' in the
HTML specification seems to match what we called 'digit'. It is not very
important but I believe it would be nicer to have 'numeric' renamed
'digit' to make things clearer and to keep the 'numeric' keyword
available in case of we need it later.

Mozilla's implementation also includes 'uppercase' which is a common use
case in the web and could be interesting but it isn't as important as
other types so it can be kept aside for later. The priority for us here
being to make the Web Platform competitive with native apps on Mobile.

Finally, it is not clear why 'tel', 'email' and 'url' are available.
Actually, tel would make sense if it wasn't already implemented as a
type (because the type is mostly an inputmode) but all of those
inputmode already have an associated type. The specification even say
"rarely necessary" and suggest to use the type. Why adding those
keywords in the first place then? I feel like we shouldn't add stuff
that we do not believe is useful. If it happens to be useful, we should
listen to feedback and see if we can fix the types (like make it easier
to have them not validate).

To conclude, Mozilla is interested in implementing this set of keywords:
verbatim, text, name, prose and digit (or numeric).
We would be interested to hear from other vendors. Is anybody planning
to implement inputmode? if that's the case, which set of keywords is
going to be implemented?

Feedback is welcome :)

[1] This is definitely working with Firefox Android Nightly, I don't
know for other channels.

Thanks,
--
Mounir