W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2013

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

From: Masayuki Nakano <masayuki@d-toybox.com>
Date: Thu, 31 Jan 2013 16:52:29 +0900
Message-ID: <510A22BD.2010106@d-toybox.com>
To: Егор Николаев <termi1uc1@gmail.com>, www-dom@w3.org

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:

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

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.

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.
Received on Thursday, 31 January 2013 07:52:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:20 UTC