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
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.
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:
Which line of code looks cleaner and more elegant to you?
There’s more to come: among others
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.
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.
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.
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.
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.
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.
If you like this blog, why not donate a little bit of money to help me pay my bills?