September 17, 2013
Issue 1 - browser-dependent key codes
An already well-documented issue is that the cmd key triggers different key codes depending on the browser. In Firefox, the key code for cmd is 224, in Opera it's 17, and Webkit browsers (Chrome and Safari) make a distinction between the left cmd key, for which the key code is 91, and the right cmd key, for which the key code is 93.
This inconsistency is not that bad, especially if you consider that all modern browsers agree that
event.metaKey refers to the cmd key.
Which leads us to Issue 2.
Issue 2 -
.metaKey not available in the
keyup event handler
When the cmd key is released, which is when the
keyup event is fired, the
metaKey property of the
event object cannot be used: metaKey becomes purely and simply invisible. If you want to work with the cmd key in the scope of a
keyup event (which is useful if you need to count the number of keys simultaneously pressed), you will have to first figure out which key code the cmd key triggered when the
keydown event was fired (those key codes are listed in "Issue 1"), and check that very key code when the
keyup event fires.
You'll have to admit it makes things quite complicated.
But it gets worse.
Issue 3 -
keyup event put on hold for other keys
As soon as the cmd key is pressed, it takes all the attention of the
keyup event, which will purely and simply forget other keys exist. It is therefore impossible to count reliably how many keys are pressed at the same time as soon as the cmd key enters the equation, which is a big problem when you're looking to capture complex key stroke combinations (many modifiers + many "regular" keys).
Those issues make it clear, in my humble opinion, that the command key shouldn't be treated as just another modifier key, at least not yet. The
event.metaKey || event.ctrlKey pattern that is often used in keyboard-centric applications can therefore lead to unpleasant surprises, unless you're just capturing combinations made of a series of modifiers accompanied by one "regular" key (which most keyboard shortcuts are made of).
For kDown, I took the decision to completely ignore the command key for the
whenDown methods as their very purpose is to monitor complex combinations (in a way, those methods consider that the command key is to a Mac what the Window key is to a PC). However, I decided to take the cmd key into account for the
whenShortcut methods, where only modifiers accompanied by one regular key are valid input to listen to (no need to count how many keys are simultaneously pressed).
Hopefully, future implementations will be more consistent with regard to the command key, as it indeed seems to be a logical UX choice to make it the equal of the
ctrlkey for Mac users.