Re: A question about key identifiers on non-alphabetic keyboards.

Hi, Bono-san-

Hironori Bono (坊野 博典) wrote (on 9/24/09 1:17 AM):
> Hi DOM3 Events folks,
> Sorry for my question.
> To read Section 6.2.6 of the latest draft, I'm wondering how we should
> select key identifiers for a Russian keyboard (and ones for
> non-alphabetics scripts).
> On a Russian keyboard with a phonetic Russian mapping (*1), the key
> labeled 'Q' (in terms of US 101 keyboard) maps to the key identifiers
> 'й' (U+0439) (unmodified) and 'Й' (U+0419) (modified).
> To follow this step, when we type the key labeled 'Q' (in terms of US
> 101 keyboard) and a control key, a user-agent should generate a
> keyboard event whose key identifier is 'й' (U+0439) and ctrlKey is
> true.


> On the other hand, I assume many web applications use the following
> snippet to handle control-key events.
>    if (evt.key == "Q"&&  evt.ctrlKey == true) {
>      // ...
>    }

The "key" attribute is defined in DOM3 Events, so I hope no code is 
using that yet.  If it is, then we need to change the name of the 
attribute, or it will conflict with existing content.

> So, straight-forwardly implementing this key identifiers may cause
> compatibility problems that web applications don't work with Russian
> keyboards (and ones for non-alphabetic scripts).
> (*1)
> The simplest workaround is changing the key identifier to 'Q' when we
> type a control key. Nevertheless, it is probably not compliant with
> this description.
> Another workaround is that a user-agent maps such control keys to a
> key identifier defined in Section 6.2.7. Nevertheless, this workaround
> doesn't work with the above code.
> (Even though using the legacy attribute 'keyCode' can avoid this
> problem, it is inconsistent across platforms as written in Section
> 5.2.7.)
> Would it be possible to give me advices about solutions for this problem?

It seems you're asking how an author can try to rely on a particular 
physical layout and key mapping to "identify" a particular key, and the 
answer is, unfortunately, you can't.  The spec talks a bit about this 
[1].  You can guess, using keyCode, but that's not any guarantee (as you 
note).  You might be able to approach it a bit more robustly, as an 
author, by not using specific key identifier string literals, and 
providing a variable "hotkey" map instead, initializing each hotkey to 
what you think is the appropriate value using language subtags [2] (e.g. 
if navigator.systemLanguage == "ru", quit = "й"; if evt.key == quit && 
evt.ctrlKey == true ... ).  But even then, you're guessing that the user 
is using a standard keyboard mapping... for example, with the Dvorak 
mapping, hitting the key immediately to the left of the tab key will 
give you a double-quote, not "q", and the user could be using a custom 
mapping as well, with any language.

The safest way right now is for the webapp to simply provide a means for 
the user to choose their own hotkeys.  This also ensures that the webapp 
isn't overriding existing hotkey functionality.

I've been thinking a lot about this, actually, and the only solution I 
have come up with is likely too over-engineered.  If the OS would expose 
the physical layout and mapping information to the browser, the author 
could use a reference keyboard layout (like ISO/IEC 9995) in combination 
with key identifiers to indicate which *physical key* they want to use 
as for particular input, and the browser would map that to the 
event.key.  It should work, but it would probably need to be specified 
somewhere, and implemented, and it would take a while to deploy.  (I 
think this may be similar to one of your suggestions above.)

I'm sorry I don't have a better answer for you.  I believe the original 
editors of DOM3 Events tried to meet this use case, but in the end, I 
don't think key identifiers alone can do this.

If people have other suggestions, especially elegant ones that could be 
included in DOM3 Events, I would very much welcome them.


-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Received on Friday, 25 September 2009 09:24:46 UTC