I'm writing a CSS book

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

contact

W3C DOM Core tests

During the past several weeks I’ve been busy writing tests and performing them, and now the result is here: the W3C DOM Core compatibility tables for desktop and mobile browsers. I wrote 185 tests plus a test harness, and performed them in 57 browsers (17 desktop and 40 mobile), for a total of 10,545 tests done.

DOM Core is the part of the DOM that’s old and reliable. It’s about getElementById(), parentNode, and appendChild(); basic functionality we’ve been using for almost ten years now and that works in all browsers. So from that perspective the tests were bloody boring. Still, they had to be done because my old DOM Core tables were from 2010.

I did not find important bugs. I found a weird compatibility pattern, though, and a promising new set of methods.

remove() and friends

Blink and Gecko now support the remove() method, which removes a node from the document. We already have methods for that, but remove() is better. Consider:

x.remove()
x.parentNode.removeChild(x)

Which line of code looks cleaner and more elegant to you?

Let’s not forget that the original creators of the W3C DOM hated JavaScript and added extra layers of complexity for the sake of adding extra layers of complexity. We have to clean up their mess now, and this is a first step.

There’s more to come: among others prepend(), before() and after() are in the works. They’re not yet supported by any browser, though.

I find these methods interesting for two reasons. First, because they are a good idea. Second, because they will serve as tracers for browser excellence. The longer a browser waits with implementing them, the farther behind on the curve it is.

As I said, Blink and Gecko support remove(). The method has gained a toehold in WebKit, too, with Dolphin and BlackBerry 10 supporting it (BB10 is incomplete, however). No trace in Trident yet, but I expect IE12 to make some steps in this direction.

When will the other WebKit-based browsers support remove()? When will any browser support the other methods? That’ll tell us a lot about where the various browsers are headed. I will keep close track of these methods; for instance, remove() will be the first method I’ll test in Safari on iOS7.

Weird pattern is weird

Then an old, old friend: setting and removing event handlers by means of the DOM attribute methods. Back in 2000 it made sense to test them, because nobody had any clue yet what the best method for setting event handlers in a DOM context was. Meanwhile we do know, and the attribute methods are all but forgotten.

x.removeAttribute('onclick');

This line of code should remove any onclick event handler from node x. It does so in all Gecko-, WebKit-, Blink-, and Presto-based browsers. Still, nobody in his right mind would ever use it in a real project.

And what about IE? Glad you asked. It’s tricky.

1. IE7 and below have a bug where this method does not work. This bug was solved in IE8. That much has been clear for years.
2. Three years ago I tested it in IE9, and the method worked fine. That’s to be expected if the bug was solved in IE8.
3. Now, however, it turns out that only IE8 and IE10 execute the code normally. IE11, and IE9 most of the time (but not always) do not: the event handler remains present.
4. W? T? F?
5. removeAttributeNode(), which is the same as removeAttribute() except for some extra complexity, mostly follows the same compatibility pattern, except that IE10 doesn’t remove the event handler, either.
6. W? T? F?

Again, this is not important. If you use removeAttribute() to remove event handlers you’re crazy and should be put in a nursing home. Still, the compatibility pattern is so weird that I spent a lot of time, as well as a Tweetstorm, on validating my test results. Maybe I’ll ask the IE team about it one day.

To be continued

Anyway, DOM Core is live. Next I will retest one CSS module in the desktop and mobile browsers that appeared since March, and then I’ll return to the DOM for some DOM HTML tests. I have to write new tests for all DOM modules, so it may take a little while.