miscoded

While working on a GMail issue I wrote this little bookmarklet for showing the details of GMail's keyboard mapping:

javascript:void((function (obj){var s='';for(var e in obj)s+=e+':'+obj[e]+'\n';opera.postError(s);})(top.js.Qj))

Tomorrow it will probably be called something else than "Qj" but today it printed out this little list in the console:

gc:GO_CONTACTS
gd:GO_DRAFTS
ga:GO_ALL
*n:SELECT_NONE
*u:SELECT_UNREAD
*t:SELECT_UNSTARRED
*s:SELECT_STARRED
*r:SELECT_READ
f:FORWARD
#:TRASH
:LAST_IM_MOLE
!:SPAM
c:COMPOSE
a:REPLYALL
n:NEXTMSG
o:OPEN
*a:SELECT_ALL
m:IGNORE
j:NEXT
k:PREV
/:SEARCH
u:BACK
s:STAR
r:REPLY
gi:GO_INBOX
q:QUICKCONTACTS
p:PREVMSG

:OPEN
gt:GO_SENT
gs:GO_STARRED
y:REMOVE
x:SELECT

I was just surprised by how many they are!

Of course most JavaScript authors use key events in rather simple ways. It may be news to you that

1. key events are not standardised
   
2. there are serious incompatibilities between browsers
   
3. localization of many key events is impossible
   
4. big, important sites mess things up
   

Hm, that sounds like a summary of JavaScript in general.

One thing at a time.. Is it non-standard to use key events? Yes. Well, the stuff that is in general use isn't standardised. The W3C DOM 3 Events working group note says nothing about popular bits like onkeypress, event.keyCode and event.which, instead it standardises stuff like textInput, keyIdentifier and keyLocation. This isn't implemented anywhere as far as I know.

Regarding browser incompatibilities, IE does not send keypress events for function keys while Opera and FireFox do, in FireFox event.keyCode is always 0 in keypress events and most authors do dodgy hacks to read event.which instead, Opera does its own thing for punctuation character keyCodes for no particular reason. Also Opera does not let you cancel Backspace presses, while FireFox doesn't allow cancelling Delete.

On localization, keys move around when you change from, say a US keyboard to a Norwegian one. Any letters that require a Shift modifier in one layout but not in the other can not be reliably detected in onkeydown/onkeyup handlers. This means keys like < > . : ; , + - / \ - you can not tell the user to press them and detect them in a keydown or keyup handler, because the keyCode value will be different on a different keyboard.

More on l10n: If you use an Input Method Editor (IME) the input will bypass key events entirely in Opera, send keydown+keyup in IE and keydown+keypress in FireFox. With an IME event, keyCode for keydown events is always 229 no matter what letter you press in both UAs while IE gets the keyCode right on keyup. (Tested with MS Japanese IME 8.1).

Also, be aware that some locales use [AltGr] to type characters, and from JavaScript this will set event.ctrlKey so if you detect the S key and the [Ctrl] key for your editor's "save" command you're wrong and all Poles will hate you unless they use a browser that hacks around that issue. This is a problem on important, major sites.

I've made a small table just to get a better overview of the popular event object properties. The simplest conclusion is that this isn't as tidy as it should be..

So, how should we turn this mess into a standard that is compatible with existing content?

• event order is keydown, keypress, keyup
  
• event.keyCode, event.which and event.charCode - the former two are commonly used with pseudo-browser-sniffing, so we can't just remove either. I haven't noticed event.charCode used anywhere but it is nevertheless a nice idea to be clearer about the key ID/character code distinction. It would be nice if event.charCode could be used in keydown/keyup handlers to detect the localized character value, getting around the problem with different keyboard locales.
  
• function keys should not send onkeypress or input events
  
• I'm undecided on whether the UA or the site should work around the AltGr-sets-Ctrl issue
  
• setting keyCode/charCode in a keypress must change the keys that get input. UA must do this in a way that does not allow websites to control for example paste actions.
  
• cancelling a keydown event must prevents keypress and default action for all keys (but not keyup)
  
• cancelling a keypress event prevents input and default action
  
• the keypress/input event must be able to handle IME input. The IME won't necessarily send one character at a time so we should have an event.data property giving the full text
  
• I don't think it's useful to send key events while the IME is handling the input. Do you really want to know that the user pressed a key with the keyCode 65 when they aren't typing an A at all? It would make more sense to me to send a keypress/input event when the user accepts the IME suggestion.
  

That's enough keys for the moment. Now I'm going to shortcut back to enter home.
No, not the keys. I meant I'll escape. Break. Shift my location.

Darn, I don't get away from thinking of keys now. Must be F8.