50

Related: JavaScript KeyCode vs CharCode

Here is some code you can try at home or in a jsfiddle:

el.addEventListener( 'keyup', function( e ) { 
    console.log( 'Keyup event' );
    console.log( e.keyCode );
} ); 
el.addEventListener( 'keypress', function( e ) { 
    console.log( 'Keypress event' );
    console.log( e.keyCode );
} );

Why is the keyCode different?

I can understand why one should use keypress only, but what I don't understand is how two key events, given the same hit key on the keyboard, give different keyCodes.

PS: I'm not worrying about legacy browsers support, I tried this in Chrome and was surprised, and couldn't find an explanation.

Community
  • 1
  • 1
Florian Margaine
  • 58,730
  • 15
  • 91
  • 116
  • The question [onKeyPress Vs. onKeyUp and onKeyDown](http://stackoverflow.com/questions/3396754/onkeypress-vs-onkeyup-and-onkeydown) is somewhat related and may also be interesting reading. – Frank Tan Sep 08 '16 at 21:48

3 Answers3

49

The events are for completely different purposes. Use keyup and keydown for identifying physical keys and keypress for identifying typed characters. The two are fundamentally different tasks with different events; don't try to mix the two. In particular, keyCode on keypress events is usually redundant and shouldn't be used (except in older IE, but see the linked document below for more on that); for printable keypresses it's usually the same as which and charCode, although there is some variation between browsers.

Jan Wolter's article on key events, already linked to in another answer, is the definitive word on this subject for me and has tables describing what each of the different properties returns for each type of key event and each browser.

Tim Down
  • 318,141
  • 75
  • 454
  • 536
  • 6
    I understand that the purposes are different, it doesn't answer the fact that the keyCode is different, even though the *keys* are the same. – Florian Margaine Jun 14 '12 at 10:03
  • @FlorianMargaine: There are tables on Jan Wolter's page showing what each property returns for each event. For WebKit (and indeed most browsers now), `keyCode` returns the same as `which` and `charCode` for `keypress` events, which is the character code corresponding to the character typed, as opposed to the key code of the key pressed (as it is in `keyup` and `keydown`). – Tim Down Jun 14 '12 at 10:08
  • 1
    I had to carefully read the article for this part: `On keydown and keyup events, the keycodes are not character codes, and this conversion will give wild results for many keys. There is no general portable way to convert keycodes to characters. You pretty much have to sense the browser type and base the key mapping on that. I don't have information on keycodes sent by international keyboards.` :) thanks for your answer btw! – Florian Margaine Jun 14 '12 at 10:16
2

There is a good article on quirksmode.org answering exactly that question. You might also want to look at Unixpapa's results.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • quirksmode especially says: `for instance, a lower case 'a' and an upper case 'A' have the same keyCode`, which is why I don't understand. Is there something I missed? The second article is linked in the related question :) – Florian Margaine Jun 14 '12 at 09:52
  • 1
    They are the same key on your keyboard, just with different modifiers (shift). Keyup/down is for the keystrokes, keypress for the typed text. – Bergi Jun 14 '12 at 09:56
  • So they should give the same keyCode. Why don't they depending on the event? – Florian Margaine Jun 14 '12 at 09:56
  • No, up and down should give the same keyCode, press *should* give 0. But IE, Opera and seemingly Chrome give the charCode on-press as "keyCode". – Bergi Jun 14 '12 at 10:03
0

Well, I stumbled upon one difference when i was trying to copy user's entry from one input of the form to some other part of the form , which I had locked for my for users to edit. What i found was, that whenever a user moved to the next label using key upon completing the input, one last keyboard entry was missed in the copied entry when I used eventListener to keypress and this got resolved on using keyup.

So, in conclusion Keypress listens to the state at the instant when the key was pressed, leaving aside the result of keypress, whereas keyup listens to the system status after the key has been pressed and includes the result of the keypress.

Mani
  • 1