Re: [whatwg] inputmode feedback

On Tue, 13 Aug 2013, Yoichi Osato 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'm not sure what this means exactly.


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

inputmode="" isn't intended to directly decide how the UI works, e.g. 
whether an IME, or what kind of IME, is provided. However, it is intended 
to let browsers make the decision on what kind of IME to provide.


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

I would be very happy to add such things, but I don't know what the needs 
are in those languages. I've been waiting for someone to elaborate on what 
exactly is needed.


> So should we add "native" attribute?

When would you use it?


On Tue, 13 Aug 2013, Ryosuke Niwa wrote:
> 
> 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.

I don't understand what the difference is.


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

Ok. What are the kinds of input tha Chinese and Korean Web sites need?


> On Mar 1, 2013, at 7:30 AM, Mounir Lamouri <mounir@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?

I don't understand the concern here. The attribute is indeed a hint; it 
doesn't tell the browser what UI to show, only what the page thinks the 
user will want to enter.


> > On 21/02/13 01:14, Ryosuke Niwa wrote:
> >> On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri <mounir@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?

Yeah, I don't really understand the suggestion above.


> It's not like we do a rigorous pattern matching to validate email 
> addresses either.

Actually, we do, or at least the spec does.

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