Event compatibility tables updated

Back in June I requested donations to pay for the time I needed to update the desktop browser compatibility tables. The community responded overwhelmingly. Today I present the first installment of my side of the promise: the event compatibility tables have been updated.

Donations are still very welcome, and now you know that this is the sort of thing your money is going to be used for.

Some things never change

I last updated these tables back in February 2009, when the hip and happening browsers were IE8 and Safari 3.1, and Chrome was completely new and still had to prove itself. Go figure.

A lot has happened in the mean time — not least my own switch to mobile. Therefore it’s good to see that some things never change: IE still doesn’t understand how the change event is supposed to work on select boxes, Safari and Chrome are still lazy about their cut, copy, and paste events, Opera still makes an ungodly mess of the keydown event, and Firefox still doesn’t support mousewheel.

All browsers but Safari still have trouble understanding that preventing the default of a click event on form fields means that these form fields are inaccessible to the user. Finally, all browsers, including Safari this time, still don’t fire change events when the user resets a form.

Good times are here again, and ancient and reliable browser incompatibility fun will once more be had by all!


Some things do change, however, and not always for good. I noticed that Safari does not allow you to keyboard-tab to links at all any more. This is not good for accessibility, and the move surprises me. I hope it’s a temporary bug. (Update: seems to be a setting. God, I hate those settings hidden somewhere deep in a menu you never heard of. Besides, why is the default setting to disable it?)

Still, there’s better news, too: Opera supports mouseenter and mouseleave. It’s the first non-Microsoft browser to do so.

I discovered the mouseenter and mouseleave events back in, I don’t know, 2002 or so, and immediately understood they’re WAY better than mouseover and mouseout because they don’t bubble up. Event bubbling is a good idea in general, but a bad idea when it comes to mouseover and mouseout.

The mouseenter and mouseleave events were a Microsoft extension, and apparently that was the reason the other browsers didn’t support them. Times changed, and now they are in the spec and Opera supports them. Good, even though it took eight bloody years. One wonders what Firefox, Safari, and Chrome are waiting for. The end of the universe?

IE9 introduced another neat feature: the select event now also fires if the user selects any text. All other browsers fire the event only if the user selects text in input fields.

Again a good Microsoft idea. The spec definitely allows this use, and it’s useful for people who need to write scripts that do something with user-selected text.

Based on past performance I estimate it will take the other browsers approximately sixteen gazillion years to implement this. Some things never change.

The change event

Speaking of change, if IE and Opera solve one single bug, we can significantly simplfy our form interaction scripts. Ideally, we’d just set one onchange event handler on an entire form and make it listen to all changes the user makes — not clicks or keystrokes or similar white noise, but actual changes that are actually important because the user actually makes them.

Only one thing stands in our way: IE and Opera still fire a change event every time the user uses the arrow keys to go to a new option in a select. This is very bad: if the user has to go down twenty options, twenty change events fire.

Instead, IE and Opera should fire one change event when the user leaves the select box, as the other browsers do. That’s all we need before we can switch over to a much easier style of writing form scripts.

Come on, guys! I’ve been working toward this for more years than I can count, and frankly I’m tired of waiting.

Error and load

I added new tests for the error and load events in order to see whether they fire for any asset. That is, if a style sheet has been loaded the load event should fire, and if the browser can’t find a JavaScript file an error event should fire. This works fine for pages, scripts, and images.

Again IE is more advanced than the other browsers: it is the only one to fire an error event for style sheets (although only the second and subsequent times the asset is loaded, which makes the exercise a bit pointless). IE and Opera also fire a load event when a style sheet has been loaded; the other browsers don’t bother.

Anyway, study the master table and dig as deep as you like.

Project overview

Since my client for this project is the web development community — you, in other words — I owe you a brief project overview.

This round of updating took me 20 hours of work, which includes writing the new test cases for the error and load events. At 50% of my rate this costs you €1,250. Since I collected a total of €3,750 back in June, there’s still €2,500 left for future updates.

I will continue the work in the near future, and I expect the DOM tables to take significantly less time. Most of the DOM already worked everywhere last time I looked, so I expect a fairly quick run through the methods and properties. Only the attributes will be problematic, as they have been ever since I started doing this work in 2000.

I hope to do some more work in September. October and early November are conference season, so after September draws to a close I won’t continue before mid-November.

Homework assignments

Finally, here are the browser vendors’ homework assignments:
















This is the blog of Peter-Paul Koch, mobile platform strategist, consultant, and trainer. You can also follow him on Twitter.
Atom RSS

I’m speaking at the following conferences:

(Data from Lanyrd)