Re: [whatwg] inputmode feedback

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?

Following Ian's graph:
http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control
How about this?
User Default Input Method
- Latin text verbatim
-- Latin name


--- Latin prose
- Native language (includes like Hiragana, Hanja, which are first character
set in  each native language)
-- Latin Full Width
-- Katakana
-- (some modes that is not first character set in native language)





On Mon, Aug 12, 2013 at 6:26 PM, Takayoshi Kochi (河内 隆仁)
<kochi@google.com>wrote:

> +Yoichi Osato, who is working on implementing inputmode spec for Blink and
> Chromium.
>
>
> On Fri, Jun 7, 2013 at 8:04 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>> On Thu, Jun 6, 2013 at 2:08 PM, Ian Hickson <ian@hixie.ch> wrote:
>> > 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.
>>
>> I think a really important question is if this is understandable to
>> authors. There's also a big risk that if these modes aren't noticeably
>> different in initial implementations, it will be hard to add such
>> differences later.
>>
>> / Jonas
>>
>
>
>
> --
> Takayoshi Kochi
>

Received on Tuesday, 13 August 2013 06:29:21 UTC