- From: Florian Bösch <pyalot@gmail.com>
- Date: Thu, 31 Jan 2013 11:12:16 +0100
- To: Masayuki Nakano <masayuki@d-toybox.com>
- Cc: Егор Николаев <termi1uc1@gmail.com>, www-dom@w3.org
- Message-ID: <CAOK8ODjTNOroGLFCX+r+xdAD++uNzaYYUcgeFjQi+84FeE8reQ@mail.gmail.com>
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