Monday, March 24th, 2008

Key events and Safari 3.1

Category: Browsers, WebKit

There has been a change in Safari 3.1 for how keypress events are handled. John Resig interviewed Yehuda Katz to get the skinny and understand why this was done.

The key comment is:

Use keydown/keyup if you want to know the key that was pressed; keypress if you want to know what text was detected.

John: At first glance through WebKit’s changes it appears as if they’ve significantly crippled the keypress event, is this the case?

Yehuda: People should not have been using the keypress event to get the character that was pressed. That’s because the keydown event only provides information about the actual key that was pressed (the A key, the right arrow, etc.), but does not tell the user what character will get added to (for instance) an input box.

Since arrow keys do not get added as text, keydown provides all the information that is needed. There were a couple of quirks with using keydown in certain cases previously which are resolved by their changes that prevent keypress from getting called if keydown’s default handling is blocked.

What this means is that if people were using keypress before (and relying on Safari’s native results for arrow keys, such as 63232), their code will break. However, this was a bad idea all along; people should use keydown to detect and block non-character keys. My mantra has always been: keydown/keyup if you want to know the key that was pressed; keypress if you want to know what text was detected.

Mihai Parparita is fixing Google Reader.

Also, Dean Edwards noted that Safari 3.1 failed Acid2 (not 3!) in a regression, but it appears a patch has landed.

Posted by Dion Almaer at 10:17 am
1 Comment

+++--
3.2 rating from 19 votes

1 Comment »

Comments feed TrackBack URI

This explains why I can’t write emails in Google Mail anymore, with shortcuts turned on.

Does anyone know if Google are on the case? Dion?

Comment by kim3er — March 26, 2008

Leave a comment

You must be logged in to post a comment.