Re: DOM Keyboard Event Level 3 questions about proposal (discussion about shortcut key on web applications)

Hi.

I don't understand the point of "key" property if it contains the same
value as "char" for printable keys, while contains empty string (or
Undetermined string) for unprintable keys.
The "new" "code" property in DOM Event Level 4 is almost the same as "old"
keyCode (on keydown, keyup). So instead to do "key" property more useful
you bring "new-old" property that discriminates the idea of "key" property.

Having in mind that we also have compositionstart, compositionupdate,
compositionend for more low-level inputing text detection, give me the
answers for such questions:
1. Why "key" should be the same as "char" for printable keys?
2. Why "key" should be modified while Shift pressed?
3. What the point of "key" if we have i18n universal "code" property?
4. What is the more developer-friendly:

switch(e.key) {}

or

if( (e.key || "").length > 2 ) { // Special keys: Spacebar, Shift, F1-F24
etc
  switch(e.key) {}
}
else {
 switch( KeyboardEvent.queryKeyCap( e.code ) ){} // printable key in en_US
standard keyboard(is that so?): WASD, Ctrl+c, Ctrl+v, etc
}
?

So my point is to bring "code" property and drop "key" property, or make
"key" property more useful and in this case, the are no needs for "code"
property.

Regards.


On Thu, Jan 31, 2013 at 2:12 PM, Florian Bösch <pyalot@gmail.com> wrote:

> DOM Event Level-*4* contains a code parameter on the keyboard event which
> is a non i18n key description. The current suggestion presented on the
> webapps-ml is to provide an API to translate that description to an i18n
> unmodified primary key symbol upon request like so queryKeyCap(event.code),
> such that meaningful shortcut displays can be presented (and captured) from
> a user but you can still store shortcut presets/saves regardless of locale.
> I think that would be a really good idea.
>
>
> On Thu, Jan 31, 2013 at 8:52 AM, Masayuki Nakano <masayuki@d-toybox.com>wrote:
>
>> Hi,
>>
>> I'd like to explain how Gecko (Firefox) converts native key events to DOM
>> key events and my idea for handling shortcut keys on web applications.
>>
>> First of all, legacy keyCode and charCode are not useful even for now,
>> especially when you want to make a web application which supports all
>> keyboard layout on all platforms. However, Firefox supports shortcut key
>> handling with all keyboard layout on all platforms (Firefox's shortcut key
>> handling is implemented by XUL and XBL which are based on XML + JS). But
>> please note that we do NOT use keyCode for handling the shortcut keys since
>> the identifier of keys are not useful and using it does not make sense.
>>
>> Gecko now defines following keyCode values with the meaning of the name:
>> http://mxr.mozilla.org/**mozilla-central/source/dom/**interfaces/events/*
>> *nsIDOMKeyEvent.idl#11<http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/events/nsIDOMKeyEvent.idl#11>
>>
>> * If pressed key is not a printable key, Gecko maps a DOM keyCode in the
>> list whose meaning is same as the native virtual keycode.
>>
>> * If pressed key is not a printable key and there is no appropriate DOM
>> keyCode in the list, then, Gecko sets 0.
>>
>> * If pressed key is printable and the input character is [0-9a-zA-Z],
>> Gecko sets DOM_VK_0 - DOM_VK_9 or DOM_VK_A - DOM_VK_Z.
>>
>> * If pressed key is printable and the native keyCode indicates [0-9] or
>> the key can input [0-9] with Shift key, Gecko sets DOM_VK_0 - DOM_VK_9.
>> This special case is for AZERTY keyboard layout.
>>
>> * If pressed key is printable and the input character is not [0-9a-zA-Z]
>> but an ASCII character, the keyCode is decided from the input character
>> without modifier keys (including Shift key). And Gecko sets appropriate DOM
>> keyCode for the unmodified character.
>>
>> * If pressed key is printable and the input character is not an ASCII
>> character:
>>   - If the keyboard layout is ASCII capable keyboard layout such as
>> German keyboard layout, Gecko sets 0.
>>   - If the keyboard layout is not ASCII capable keyboard layout such as
>> Arabic keyboard layout, using the most preferred ASCII capable keyboard
>> layout in the system. If the key inputs [0-9a-zA-Z] on the ASCII capable
>> keyboard layout, Gecko sets DOM_VK_0 - DOM_VK_9 or DOM_VK_A - DOM_VK_Z.
>> Otherwise, 0.
>>
>> These rules are used Firefox 15 and later.
>> https://developer.mozilla.org/**en-US/docs/DOM/KeyboardEvent#**
>> Virtual_key_codes<https://developer.mozilla.org/en-US/docs/DOM/KeyboardEvent#Virtual_key_codes>
>>
>> However, as I said above, the DOM keyCode loses a lot of information. So,
>> it's not enough to support shortcut keys.
>>
>> Therefore, Gecko lists up shortcut candidate characters when Ctrl key or
>> Alt key are pressed. And Gecko sets the list into the key event (the list
>> is not accessible from Javascript).
>>
>> XUL applications don't need to handle key events for supporting shortcut
>> keys. They just register the shortcut key with <key> element.
>>
>> And Gecko compares <key> element's key specification with each list item
>> of the candidate list in the key event. If it's matched, the handler
>> specified by <key> element is kicked by Gecko.
>> https://developer.mozilla.org/**en-US/docs/Gecko_Keypress_**Event<https://developer.mozilla.org/en-US/docs/Gecko_Keypress_Event>
>>
>> But unfortunately, the comparing rule is very complex. So, I think that
>> it doesn't make sense the candidate list to be accessible from Javascript
>> and *each* web developer implements similar system.
>>
>>
>> In conclusion, I think that web standards should define shortcut key
>> registration mechanism for web applications. And UA should hide the complex
>> work from web application developers.  Then, all web applications can
>> support all keyboard layouts all over the world easily. I believe that this
>> is the best way for i18n of web applications.
>>
>> However, yes, I know some other web applications need to handle key
>> events directly even if there is the shortcut key registration system.
>> Therefore, I think that KeyboardEvent.char and KeyboardEvent.key are also
>> needed and useful.  I'll post another email into this thread later for them.
>>
>> --
>> Masayuki Nakano <masayuki@d-toybox.com>
>> Manager, Internationalization, Mozilla Japan.
>>
>>
>