PPK was in California last week and he was kind enough to visit Yahoo and deliver a tech talk outlining some of the interesting browser-event work he’s been doing. We’re happy to share that talk with you on YUI Theater. Slides from PPK’s talk are available in PDF form here.
In Case You Missed…
Some other recent videos from the YUI Theater series:
- Jenny Donnelly: Hacking with YUI
- Nate Koechley: Professional Frontend Engineering
- John Resig: The DOM Is a Mess
- Nicole Sullivan: Design Fast Websites (Don’t Blame the Rounded Corners
Subscribing to YUI Theater:
Peter-Paul Koch: Thank you for inviting me, once again, to speak at Yahoo!. I’m PPK: Peter-Paul Koch, but everybody calls me PPK. It’s a long story. I run a site called http://quirksmode.org, where you can find information about browser incompatibilities. And I have a Twitter account, obviously — who doesn’t?
If you don’t know where my compatibility table is, here at http://quirksmode.org/dom/events. Use it to look up some complicated events stuff that you want to know about.
But first: the key events. It all seems so simple. There are three key events – keydown, keypress, and keyup. And people generally think they know exactly when they fire. I’m here to tell you that it isn’t always as clear as you think it is.
Let’s go through some quick definitions. The keydown event fires when a key is depressed by the user, and it keeps on firing as long as the user keeps it depressed. That’s simple. The keypress event, basically that’s the same, except that it fires only when a character key is depressed – in other words, a key that will lead to a character being inserted into, say, a textarea. Finally, the keyup event fires when the user releases the key. Well, that’s all pretty simple.
Just to make absolutely sure that everybody understands – if I press, say, an ‘o’ key, or an ‘i’ key, or one of these strange bracket keys, both a keydown and a keypress event will fire. On the other hand, if I press special keys such as the shift key, or the arrow keys, only a keydown event will fire.
This theory of the difference between keydown and keypress originated with Microsoft. All the Internet Explorer versions actually use this difference between keydown and keypress. And Safari has copied it, as from version 3.1, I think, which was released about a year ago, maybe slightly more. The point is, here, that this theory is the only theory about the difference between keydown and keypress in existence. In contrast, Opera and Firefox just fire lots of events at you all the time, because it is tradition that it is both a keydown and a keypress event, so we should fire both whenever we see an opportunity. Which is fine, but it doesn’t explain why there should be two events, instead of just one: the keydown event. So that’s why I kind of like this theory of the difference between keydown and keypress.
So, let’s repeat it once more. Keydown fires when a key – any key – is depressed. Keypress fires when a character key is depressed. And as we can see here, it works in IE, and in Safari. Oh, and I don’t have Google Chrome items here yet, but assume that anything that works in Safari also works in Google Chrome. They are really quite close, these two browsers.
OK, so let’s move on to some practical questions. Usually when you write a script that detects user keys, he wants to know which key the user pressed, and do some interesting interface stuff based on that.
Now, there are two properties that any key event carries – those are the keyCode, and the charCode properties. And there are also two bits of data you might want to know about – the key code, and the character code. And the difference is, the key code is the actual code of the physical key the user depresses, and the character code is the code of the resulting character. So, if I press an ‘a’ key, I get key code 65, because the ‘a’ key has the code 65. But the character code is 97, for a lower case ‘a’. If I press a shift key, I get key code 16, because that’s shift – but I do not get a character code, because the shift key, by itself, doesn’t result in any character. Well, that sounds simple.
So we have one property – we have, actually, two properties, and two bits of data. And having one property containing one bit of data, and the other property the other, would of course, be far, far too simple. It would mean that you don’t need a specialized content engineers, that anyone can just write a key script, which is obviously not the idea.
So, what exactly is going on? It’s pretty complicated, actually, and frankly, I do not understand entirely why it should work like this. But it does work like this. The keyCode property. With a keydown event, onkeydown, it contains the key code – the code of the physical key the user depresses. Onkeypress, on the other hand, contains the character code – basically, the ASCII code of the character that appears on the screen. And this works in all browsers – except that in Firefox, onkeypress shows zero for key code; don’t ask me why. Then, charCode. Onkeydown, charCode returns zero, and onkeypress, charCode returns the character code. And this, too, works only in Firefox and Safari, because these are the only browsers to support charCode.
Let’s move on to something really practical. If you need the actual key that the user depressed, the physical key, use the keydown event and ask for the keyCode. That will work in all browsers. On the other hand, if you needed the character the user has just entered in a text area, or whatever, you should use the keypress event, and ask for either keyCode or charCode – one of them will contain the information you’re looking for in the browser.
Finally, sometimes you want to prevent the default action of a key. I’m especially thinking of arrow keys. Suppose you have a keyboard accessible drag and drop menu, and then you want the user to be able to manipulate the drag element by the arrow keys, and you want to cancel the default of the arrow keys – namely, scrolling the page. Basically, you should do that onkeydown, because, as I said before, keydown fires when any key is depressed, and keypress only fires when character keys are being depressed. Unfortunately, this does not work in Opera – and I must admit I did not test it the latest Opera, so it might have changed there. And preventing arrow keys in Opera is something I’m not going to talk about today, because frankly I forgot the answer.
That concludes the key events. It is not really complicated, all those key events, but you have to be aware of the difference between keydown and keypress.
Now, the change event. In theory, the change event would be absolutely wonderful to have, because the change event fires when the value of the form field is changed. Often, you want to detect everything the user does in a form – for instance, onformsubmission, you of course want to go through all form fields and validate them. But there’s also ways of making a form – or form fields, checkboxes for instance – a kind of menu that the user can use to go through a complicated interface. And what you want to do, always, is see what, exactly, that the user changed in the form. And in theory, the change event would be absolutely wonderful for that.
But usually, we are forced to use the focus or blur events instead – or maybe the click event, in the case of detecting a checkbox changes – because the change event doesn’t work quite correctly. We’re to distinguish three different cases. First of all, the change event of text fields; second, on select boxes; and third, on checkboxes and radios.
We start with text fields. And I suppose the user focuses on a text field, in any way, either by the mouse or the keyboard, and then blurs again. In other words, he moves on to the next field. In that case, no change fires, because there’s nothing that has changed – the value of the text field has not been modified. But if we change it slightly – if we say the user focuses on the text field, and then enters something, then blurs the text field, then a change event fires at the moment the user blurs the text field. Because the value of the text field has been modified, and that obviously causes a change event. This is all good; this works perfectly in all browsers.