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: Florian Bsch <pyalot@gmail.com>
Date: Thu, 31 Jan 2013 11:12:16 +0100
Message-ID: <CAOK8ODjTNOroGLFCX+r+xdAD++uNzaYYUcgeFjQi+84FeE8reQ@mail.gmail.com>
To: Masayuki Nakano <masayuki@d-toybox.com>
Cc: (wrong string) •го€ иколаев <termi1uc1@gmail.com>, www-dom@w3.org
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.
Received on Thursday, 31 January 2013 10:12:48 UTC

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