Sort out issues with [inputmode]

[travisleithead]

Moved from Bugzilla: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23961
@sicking, @benbucksch, @TakayoshiKochi

In the linked bug, it is pointed out that inputmode combines concepts in one attribute that shouldn't logically belong together (script/language [latin, kana...], data types, and typing aids, etc.).

Is this feature widely implemented? Should it be dropped? If not, can it be refactored to make sense? Mozilla seems to have had an interest in addressing some of these concerns.

[sicking]

I think @mounirlamouri and I reached a good proposal, but I've forgotten it all by now.

[arronei]

Additional bug that needs to be addressed. https://www.w3.org/Bugs/Public/show_bug.cgi?id=27229

[benbucksch]

Description from linked bug:
Latin and kana are orthogonal to things like "autocorrect off".
Likewise, "email" belongs in type, and is already standardized and accepted cross-browser there, but inputmode has it as well - again: orthogonal.
So, the current spec has 3 or more orthogonal aspects in the same field:

1. script/language (latin, kana...)
2. data type (text, numbers, email, url)
3. typing aids
   3.1. completion / text prediction
   3.2. correction
   3.3. capitalization
   3.4. spell checking

They are orthogonal, because I can have completion, correction and even capitalization for names (using the user's address book) and for text (using a dictionary). They'd use different algorithms, but still the type (name, text) is a different aspect from whether I want the computer helping my type or not.

That all doesn't seem well-thought out, and Mozilla thinks so, too:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org//2013-February/038914.html

This whole definition of inputmode seems off, because in my usecase, it is actually "prose" text that the user enters. But the prose contains special abbreviations and terms that I need to recognize, and Firefox OS' autocorrect wrongly "corrects" these, too, rendering this form and app feature useless. So, I actually do want to say that it's "prose" text (inputmode="prose"), I just want to tell Firefox OS to get out of the way. An autocorrect="off" seems like a much better way to turn off one specific malfunctioning feature than saying inputmode="verbatim", which would disable all typing aids. I have nothing the autocomplete suggestions that Firefox OS shows in the row above the virtual keyboard, but inputmode="verbatim" disables these as well.

This is why I think that autocorrect on/off/default should be a boolean (3-state) flag, which is independent from any other dimensions like language or data type.

[benbucksch]

I propose to split up the different aspects:

For 1. above:

• inputscript="latin"/"kana" etc.
  default is chosen by browser based on language of page and user.
  See http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org//2013-February/038914.html

For 2. above:

• type="email"/"url"/"text"
  As already specced

For 3. above:

• autocorrect="off" (change words that the user already typed)
• autocapitalization="off"
• spellcheck="off" (underline misspelled, with aids to correct on user action)
• typingaids="off" (Swipe, word suggest; not changing letters the user typed)
  I'm not sure about this last one.

[scunliffe]

The inputmode attribute/feature is not widely implemented yet however getting it implemented will help overcome current issues with the new text-like input fields. Currently to get a numeric keyboard to appear on mobile we want to use type="number" (for usability)... However this applies very strict conditions to the field, specifically restricting setting partial values via JavaScript and using text selection methods to get/set the caret position/selection.

[duerst]

I agree that some more thought is needed for this attribute.

On the one hand, there may be too much stuff mixed together. Inputmode should always be a hint, with other attributes being responsible for strict checking. How these work together can be complex, and needs to be thought through carefully. And new technology (e.g. smaller virtual keyboards on smartphones, and the next new thing we don't know yet) may change what's needed. The goal is to help the user avoid switching keyboards as much as possible.

On the other hand, as of today, the scripts covered seem to be extremely restricted (just Latin and Japanese). https://www.w3.org/TR/2006/REC-xforms-20060314/sliceE.html contains many more scripts, and I'm sure many of them are useful to speed up input in many places around the world.

[scunliffe]

I realize that there are multiple tokens for the inputmode attribute that may stir up discussions however I should clarify that my concerns are almost entirely around the "digits"/"numeric" hints. I am currently _extremely_ frustrated with the <input type="number"/> specifications that severely restrict how the field is populated and interacted with to the point that my code now has to actively test how strongly a browser follows the spec on-the-fly and reset the type attribute back to text if really strict.

When the inputmode attribute supports "digits" or similar it will provide a permanent solution to "hint" for a numeric keyboard without having to use the (IMHO) broken type="number" attribute.