W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2009

Key Identifiers

From: Øistein E. Andersen <liszt@coq.no>
Date: Thu, 5 Nov 2009 22:47:55 +0000
Message-Id: <4B7E3631-3586-4B45-B622-8D161B74E623@coq.no>
To: www-dom@w3.org
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] <http://coq.no/widget/tastiera/en>
[2] <https://bugs.webkit.org/show_bug.cgi?id=30652>
Received on Friday, 6 November 2009 01:49:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:04 GMT