[whatwg] inputmode feedback

[Ian Hickson]

On Wed, 13 Feb 2013, Mounir Lamouri wrote:
> 
> 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"

(Also "full-width-latin".)

> but in none of those situations "latin" is mandatory.

While I think it's appealing, from an abstract perspective, to view the 
script and mode as orthogonal here, it seems to me that in reality 
keyboard combine them into a single UI. I fear that separating them would 
lead to a lot of meaningless combinations being possible.


In general, though, this is not my area of expertise and I'm happy to 
defer to whatever is implemented (as with anything else).

(I looked at iOS and Android and considered just mapping all the values to 
HTML keywords, but that would have made the actual list even more complex, 
so I just hit the highlights.)


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

What's the difference between these two, and why is "digit" a better name 
for it than "numeric"?


> Finally, it is not clear why 'tel', 'email' and 'url' are available. 

Mostly it's for letting people build custom UIs (e.g. a Web component 
that implements type=tel).


On Fri, 15 Feb 2013, Jonas Sicking wrote:
> 
> Using semantic names might give us the warm fuzzies, but is there really 
> any semantic use we will get out of these that we wouldn't by using 
> "lowercase", "titlecase" or "autocapitalized"?

The reason I used the more "semantic" names is that the names like 
"lowercase", "titlecase" or "autocapitalized" aren't accurate. For 
example, you can hit shift in "lowercase" mode to get uppercase. You can 
have a "titlecase" mode that doesn't capitalise every word (e.g. it 
recognises the "van" in "van Kesteren"). A value that is explicitly for 
names can use a different dictionary than one that is just for capitalised 
text (e.g. derived from the user's contact list). And so on.


> I take it verbatim and name would disable any spelling corrections,
> and name would also titlecase? But the difference between text and
> prose seems really hard to understand.

In the spec, "verbatim" does not correction at all, e.g. passwords; 
"latin" is for human-to-computer communications, e.g. free-form text 
search fields, and would do spelling correction and automatically 
inserting spaces between words in swiping keyboards, etc; and 
"latin-prose" is intended for human-to-human communications, with 
aggressive automatic typing correction, e.g. text prediction and automatic 
capitalisation at the start of sentences.


On Fri, 1 Mar 2013, Mounir Lamouri wrote:
> > 
> > People may want to control IME input mode like the way Flash can,
> >
> > http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/IME.html 
> > but it it is unfortunate that controlling IME from web apps is so 
> > distributed (CSS, input attribute, DOM lv3 compositionevent and IME 
> > API).
> 
> As I see it @inputmode isn't here to be a feature like this but maybe 
> Hixie had a different vision when he wrote the specs for it.

inputmode="" is mainly intended to control what keyboard to use on mobile 
devices.


> Maybe if it was named @inputhint and the user was allowed to change the 
> input mode, it would be clearer?

Everything in HTML is a hint. The user's always in control.


I haven't changed the spec for now, but as noted above, I don't a priori 
object to making changes, even radical changes, to this part of the spec, 
if they make sense. :-)

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