Key Identifiers

According to a note in the draft, ‘the “keydown” and “keyup”  
events are traditionally associated with detecting a physical key  
rather than a character value’, but the current model does not seem  
to allow a physical key to be detected.

For some use cases, what matters is the physical position of a key,  
irrespective of keyboard layout, and not the character produced when a  
particular keyboard layout is active.  For instance, the MacOS X  
Widget ‘Tastiera’ [1] maps keys to piano keys; for this  
application, a Q on a QWERTY keyboard is equivalent to an A on a  
French (AZERTY) keyboard, to an Й on an Old Russian (ЙІУКЕН)  
keyboard, etc., but DOM Events does no seem to provide a unique  
identifier corresponding to the physical key variously producing a Q,  
an A, an Й, etc.

Mac OS X Cocoa's NSEvent (for the sake of a concrete example) provides  
‘charactersIgnoringModifiers’ similar to DOM Events'  
KeyboardEvent.key (though it uses unescaped Unicode characters in the  
returned string, which seems preferable, but that is a different  
discussion), but also ‘keyCode’ which identifies a physical key by  
means of a hardware-independent, virtual key code (probably inherited  
from ADB).  Other platforms presumably have similar functionality, and  
it would be great if an attribute allowing a physical key to be  
identified could be added to DOM Events as well. An existing set of  
scan codes could be adopted, or a more systematic area/row/column  
enumeration scheme could be envisaged.


This is somewhat related to a WebKit bug on keyup/keydown events and  
dead keys [2].  The DOM Events draft suggests that dead keys should be  
represented by Unicode combining characters, which may well be the  
best solution available; it might be worth pointing out, though, that  
the two concepts are different in that a dead key is pressed before  
the corresponding letter key whereas a combining character comes after  
the corresponding letter (i.e., naïve would be typed na¨ive with ¨  
being a dead key, but represented as nai¨ve in Unicode with ¨ being a  
combining diacritic).

Øistein E. Andersen

[1] <>
[2] <>

Received on Friday, 6 November 2009 01:49:26 UTC