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

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

-Charles


-Charles

Received on Monday, 22 August 2011 08:04:03 UTC