In Safari 3.1, which was released yesterday, the keypress event is no longer fired for non-character keypresses other than enter.
I was sure this was just a bug, but it turns out the change was intentional, and was made in order to imitate the behavior of Internet Explorer.
In other words, the WebKit team looked at their keypress implementation, which had some quirks but at least worked more or less the same as in Firefox and Opera, and they said, “Hey, you know what this needs? More suck!” and changed it to work like IE instead, thereby causing even more confusion in the already-muddled clusterfuck of DOM keyboard events.
If you’re developing a web browser, here’s a helpful tip: when faced with the question of whether you should imitate the behavior of Internet Explorer or [insert other browser name], always imitate the other browser. I don’t care if the other browser is Mosaic 1.0; odds are it’s a safer choice than IE.
Comments
Huh.
I had almost finished what had turned into quite a long comment about how this really made sense for i18n reasons… and then thought about it some more and realized that my whole argument was moot given that the new
keypressevent still passes the “enter” key through. If they’d decided to remove all non-character generating keys fromkeypress’s repertoire, and just relegated them tokeydown, that’d be one thing. But to only allow certain non-character codes through, while blocking others… that just don’t make no sense. Dang. Hopefully they’ll come to their senses and restore the Gecko-flavored API.Of course, what’d really be great would be for the browser makers to actually put together a useful and consistent keyboard event-handling API. I know, I know, I may as well ask for a pony, flying cars, and cities on the moon while I’m at it; and even if I did get my beautiful shining API we’d all still be stuck supporting the broken-ass legacy APIs forever. Still, though, a guy can dream.
Re: Huh.
Yeah. I understand their reasons for making the change, and it does actually make sense from an internal consistency standpoint, but it’s a horrible idea from a browser compatibility standpoint.
I wish they would have actually discussed this with developers before implementing it. When the only notice about such a backwards-incompatible change is a single post on the webkit-dev mailing list, there’s a serious communication issue.
True
Ain’t that the truth. Seems to me like changes that affect browser compatibility would be Big Deals, and require lots of discussion. I wonder what the internal webkit backstory is?
Appropriate use of the work Clusterfuck
Nuff said