[whatwg] inputmode feedback

[Ryosuke Niwa]

On Aug 12, 2013, at 11:28 PM, Yoichi Osato <yoichio at google.com> wrote:

> I have questions about some inputmode attributes.
> In the desktop case, full-width-latin, kana and katakana look to intend
> user local IME. Right?
> I think whether IME is on or off is very important to user because some IME
> have state and show some window to input character.
> It is much different from alphabetic direct keyboard input.
> See
> https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html#composer-section
> At least Chinese and Korean IME have state.
> In this point we should add attributes corresponding to chinese and korean.
> I don't know whether there are any other such a IME but I think many non
> English native people input in alphabet or hir/her native language.
> So should we add "native" attribute?

I think we need to separate the use case for controlling IME mode and hinting UA as to which type of text/script will be entered as Mounir suggested in the original email.

And I agree that we need to address Chinese and Korean IME use cases if we're adding Japanese IME use cases.  Also, IME behavior is very different depending on whether you're using pinyin or zhuyin/bopomofo in Chinese IME so we might need to differentiate those two as well.


On Mar 1, 2013, at 7:30 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:
> On 15/02/13 08:28, Takayoshi Kochi (河内 隆仁) wrote:
>> That said, even though authors of web apps may want to force the IME
> mode or
>> its script mode for user's sake, it may cause user's confusion as they are
>> so accustomed to change mode manually where such mode is required.
>> So if a web app sets some mode, the user may toggle it back to unintended
>> mode
>> and get frustrated.
> 
> I tend to agree. In one hand, I believe that users might get irritated
> if they can't control the inputmode but in another hand, forcing it
> might fulfil use cases where authors use Javascript to force a user to
> type in uppercase for example (that happens in a few forms).

On the other hand, inputmode is supposedly only a hint, right?   It doesn't affect the validation state of input elements.  Given that, how does it address such a use case?

> On 21/02/13 01:14, Ryosuke Niwa wrote:
>> On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri <mounir at lamouri.fr>
> wrote:
>>> To conclude, Mozilla is interested in implementing this set of keywords:
>>> verbatim, text, name, prose and digit (or numeric).
>> 
>> Why is name not an input type?
>> 
>> How does one decide whether a given semantics should be introduced as
> a type or a mode?
> 
> I tend to prefer <input type='text' inputmode='name'> over <input
> type='name'> because <input type='name'>, for the moment would be
> nothing else but a text field with an address book autocompletion. I
> would prefer to have 'tel' that way instead of having it a type FWIW.

But isn't type=email also a text field with autocompletion, no?  I agree that the UI might be similar on desktop browsers, but it could be completely different on mobile operating systems where UA could show a custom keyboard suitable to type in human names as opposed to arbitrary text.

How is that different from type=email where UA is supposed to assist user type in an email address?  It's not like we do a rigorous pattern matching to validate email addresses either.

- R. Niwa