Re: [DOM3 Events] Is KeyboardEvent.getModifierState() enough for web app developers?

On 2011/08/22 17:03, Charles Pritchard wrote:
> On 8/21/11 11:15 PM, Masayuki Nakano wrote:
>> Hello.
>>
>> KeyboardEvent.getModifierState(keyArg) checks only a key state of
>> keyArg. In other words, it cannot check whether actual modifier key
>> states are strictly same or not. For example, when a web app developer
>> want to check Ctrl+Shift key for implementing shortcut key,
> ...
>> some keyboard layouts for Mac provides some ASCII characters only when
>> Alt (Option) key is pressed. Then, |!event.getModifierState('Alt')|
>> blocks the expected behavior unexpectedly.
>>
>> # 'Alt' is strange for 'Option' key of Mac, it's rather similar to
>> 'AltGr' according to this issue...
>>
>> I think that the i18n of shortcut key issues are too difficult to be
>> resolved by each web developer. If DOM3 would provide shortcut key
>> registration mechanism at EventTarget, it would be great.
>>
>
> Does this work with the isComposing option you suggested?
>
> On a Mac, if the UA vendor catches the a11y concern, they'll ensure that
> isComposing is true on keydown and false on keyup?

I thought simply. The isComposing should be true during compositionstart 
and compositionend.  I don't think all web developers should do this 
themselves.

var isComposing = false;

function onComposition(event)
{
   isComposing = (event.type != "compositionend");
}

window.addEventListener("compositionstart", onComposition, true);
window.addEventListener("compositionend", onComposition, false);

> I've not studied this well enough, but I have worked a bit on keyboard
> events and a11y, and your isComposing proposal seems to me to be quite
> solid.
>
> As an author, I can check for isComposing on keydown, and if it was set,
> when I get my onkeyup, I'll know that modifier keys, as well as, simply,
> the value of the content, may have changed.
>
> Via webkit, Google added an AT for voice recognition, and it plugs into
> the input type="text" field (as well as textarea now, I believe) and
> queries their servers.
>
> While they currently use "change" events, textarea is better served by
> the keyboard events model.
>
> If someone were to speak: "back one word", I would set the caret
> position in the textarea/contentEditable, then send it a single key
> event corresponding to the back arrow key. Because it's an AT, I'd use
> isComposing true, on the keydown event, and false, on the keyup event.
>
> Apple's en-US IME seems to work well enough with it:
> alt n: ˜
> alt n + n: ñ
>
> keydown "˜": alt && isComposing

I think this is !isComposing. See the event order:
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#keys-DeadKeys

> keyup "˜": alt && isComposing
> keydown "n": alt && isComposing
> keyup "˜": alt && !(isComposing)
>
> A "pure" voice input would maintain isComposing=true when it sends data
> input through paste / dataTransfer.
>
> Wacom has a publicly accessible plugin for various browsers, and they
> use "isWacom" as a flag to interface with mouse events.
>
> With those two cases in mind, I think that an isComposing flag into the
> DOM Core would serve IMEs on both keyboard and mouse events. IME-mouse
> events (such as ink [pen]) are similar to keyboard-based dataTransfer
> events [paste]. Both IME (keyboard/mouse) register activity through
> basic keyup and mouseup events.

Sounds nice.  But I find an issue about this by your suggestion.  Even 
if the window (or event target) doesn't have composition, isComposing 
may be true if IM context is shared with other windows and the content 
has composition string. I mean, isComposing of mousemove events on 
different window may be true.

-- 
Masayuki Nakano <masayuki@d-toybox.com>
Manager, Internationalization, Mozilla Japan.

Received on Wednesday, 24 August 2011 01:01:51 UTC