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

And as I said in relevant thread (DOM Keyboard Event Level 3 questions
about proposal) we have "location" property witch contains one of [
KEY_LOCATION_STANDARD, KEY_LOCATION_LEFT, KEY_LOCATION_RIGHT,
KEY_LOCATION_NUMPAD, KEY_LOCATION_MOBILE, KEY_LOCATION_JOYSTICK ] value.

In my opinion,
for "location" = KEY_LOCATION_STANDARD, "key" property should match the
unmodified character values of a normal QUERTY (en-US) layout.
For "location" = KEY_LOCATION_MOBILE or KEY_LOCATION_JOYSTICK, "key"
property should match some universal i18n value, which should be described
somewhere.

Examples:

Ctrl+Ñ‹: {key: "s", char: "", ctrlKey: true, location:
KEY_LOCATION_STANDARD }
Ñ‹: {key: "s", char: "Ñ‹", location: KEY_LOCATION_STANDARD }
Shift+s: {key: "s", char: "S", shiftKey: true, location:
KEY_LOCATION_STANDARD }
Shift+ы: {key: "s", char: "Ы", shiftKey: true, location:
KEY_LOCATION_STANDARD }

On mobile:
s: {key: "<?>", char: "s", location: KEY_LOCATION_MOBILE  }
Ñ‹: {key: "<?>", char: "Ñ‹", location: KEY_LOCATION_MOBILE }

where <?> is undefined for now and it should be described anywhere.

Where are the same problem with "code" property. What values should it have
for the "logical" same keys. For examples, for S in WASD keys
(first-shooters important keys).
Should it be KeyboardEvent.queryKeyCap( event.code ) == "s" for the
char="Ы" (event.shiftKey=true), char="ы", char="S" and  char="s" both on
desktop and mobile? And why we can't bring similar logic to the useless
"key" property?

Regards.


On Tue, Feb 5, 2013 at 11:41 AM, Егор Николаев <termi1uc1@gmail.com> wrote:

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