I'm writing a CSS book

JavaScript archives Compatibility Thidrekssaga QuirksBlog Donations CSS book Politics Mobile About COH

contact

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!

Changes

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:

IE

MAJOR

• The change event on select boxes should fire only once when the user is using the keyboard: when the user leaves the select box. It should not fire every time he hits an Arrow key while searching for the correct option.

MINOR

• The change event should fire on all relevant elements when the user resets a form.
• When the default of the click event is being prevented, no radio buttons should become unchecked if the user clicks on one.
• Also fire an error event the first time a non-existing asset is loaded into a <link> tag.

Firefox

MAJOR

• Support mouseenter and mouseleave. Now!
• Support mousewheel.
• Support focusin and focusout.
• Don’t fire the keypress event for non-character keys.
• Display iframes in 7.0b Windows.

MINOR

• 6.1 Mac: Fire focus and blur events on radios and checkboxes when the user uses a mouse to toggle them. (Maybe this bug is solved in FF7.)
• Fire the select event when the user selects text anywhere.
• The change event should fire on all relevant elements when the user resets a form.
• When the default of the click event is being prevented, clicking on a select box should not allow the user to access that select.
• When the default of the click event is being prevented and no radio is checked in a certain group, you should not check the first radio button the user clicks on.
• Fire an error event when a non-existing asset is loaded into a <link> tag.

Safari

MAJOR

• Support mouseenter and mouseleave. Now!

MINOR

• Fire focus and blur events on radios and checkboxes when the user uses a mouse to toggle them.
• Support the resize event on resizable elements (resize: both;).
• Allow traditional registration of focusin and focusout, like in element.onfocusin = function () {etc}.
• The change event should fire on all relevant elements when the user resets a form.
• Windows only: The cut, copy, and paste events should only fire if there’s something being cut, copied, or pasted. Right now they fire whenever the user hits the keyboard shortcuts.
• Fire an error event when a non-existing asset is loaded into a <link> tag.
• Fire the select event when the user selects text anywhere.

Chrome

MAJOR

• Support mouseenter and mouseleave. Now!

MINOR

• Fire focus and blur events on radios and checkboxes when the user uses a mouse to toggle them.
• Support the resize event on resizable elements (resize: both;).
• Allow traditional registration of focusin and focusout, like in element.onfocusin = function () {etc}.
• The change event should fire on all relevant elements when the user resets a form.
• When the default of the click event is being prevented and no radio is checked in a certain group, you should not check the first radio button the user clicks on.
• The cut, copy, and paste events should only fire if there’s something being cut, copied, or pasted. Right now they fire whenever the user hits the keyboard shortcuts.
• Fire an error event when a non-existing asset is loaded into a <link> tag.
• Fire the select event when the user selects text anywhere.

Opera

MAJOR

• The change event on select boxes should fire only once when the user is using the keyboard: when the user leaves the select box. It should not fire every time he hits an Arrow key while searching for the correct option.
• Don’t fire the keypress event for non-character keys.
• Repeat the keydown event when the user keeps a special key depressed.
• Allow the default to be prevented onkeydown.
• Fire an unload event when the user navigates away through some mechanism other than a link.

MINOR

• The change event should fire on all relevant elements when the user resets a form.
• When the default of the click event is being prevented, no radio buttons should become unchecked if the user clicks on one.
• When the default of the click event is being prevented, clicking on a select box should not allow the user to access that select.
• Fire an error event when a non-existing asset is loaded into a <link> tag.
• Fire the select event when the user selects text anywhere.