I was (clearly) still a little frustrated when I posted about the Safari 3.1 keypress change the other day, and in my frustration I posted a rant when a reasoned discussion would have been more productive. As my coworker Julien said to me later that day, “Nobody died!”
After seeing my rant, John Resig posted a more in-depth discussion of the change and the reasons behind it. I don’t disagree with his conclusions. The reasons for the change are good, and it was something that needed to happen. I only have two complaints:
- The WebKit team should have communicated the change to web developers before Safari 3.1 was released. A blog post on the WebKit blog would have sufficed. The only pre-release notification I’ve been able to find about the change was a single email to the webkit-dev mailing list, a list that few web developers subscribe to since it focuses on internal WebKit development rather than on web development with WebKit.
- Even though the new behavior is more “correct”, it fragments the already-fragmented world of DOM keyboard events even further. In one camp you have IE and Safari 3.1, which now behave similarly but still have minor differences. In the other you have Firefox, Opera, and Safari 3.0.
The cross-browser inconsistencies are frustrating, but they’re nothing new, and they can be dealt with. The communication issue is the one that bothers me the most. It’s the reason I was so annoyed when I saw my code break in Safari 3.1. The fact is, I love Safari, almost to an unhealthy degree; it’s been my browser of choice for a few months now and I’ve come to expect the best from it. Seeing an incompatible change like this slip into a major release with no warning was a bit like having the first argument in a new relationship: it came out of nowhere and left me feeling like the world was ending when, in hindsight, it wasn’t really such a big deal.
To sum up: changes that break backwards-compatibility are okay when there’s a good reason, but give us some warning next time. I still love you, Safari.