- From: Øistein E. Andersen <liszt@coq.no>
- Date: Thu, 5 Nov 2009 22:47:55 +0000
- 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 UTC