For reasons relating to dynamic loading of javascript dependencies, I wanted to find a way to tell:

1. When a script tag finishes loading a file
2. Whether that file was successfully loaded

For various reasons, I didn’t want to add cruft into the files being loaded — no appending a function call to the end of every file, or anything.

Now, the finishes-loading case turns out to be pretty easy, albeit with some quirky cross-browser ramifications:

var eax, load;
eax = document.createElement('script');
eax.setAttribute('type', 'text/javascript');
eax.setAttribute('src', src);
load = function(e) {
    // FF/Safari get the `load` handler, IE gets the `readystatechange` handler.
    // IE doesn't fire 'load' for JS (but does for CSS...)
    if(!eax.readyState || eax.readyState == 'complete' || eax.readyState == 'loaded') {
        // IE6 stalls at 'loaded' sometimes
        alert('loaded!');
        // remove these listeners for everyone, because it's
        // easier than testing everything to find out whether it's needed.
        removeEventListener(eax, 'readystatechange', arguments.callee);
        removeEventListener(eax, 'load', arguments.callee);
    }
};
addEventListener(eax, 'load', load); // FF/Safari get this
addEventListener(eax, 'readystatechange', load); // IE gets this

It’s a horrible mish-mash of events, obviously, but it works. Insofar as it goes.

Working out whether the load was successful turns out to be the hard part.

In Firefox it’s very easy. The load event doesn’t fire if there are problems loading the JS file, and a error event fires instead. This is lovely.

In Safari the load event doesn’t fire if there are problems, but there’s no other sign given. So I could probably fake this with a setTimeout set to a reasonable length — not perfect, but good enough for most cases.

In IE the readystatechange event fires away regardless. It’s here that I’m stuck — I can’t see any way to tell, in the readystatechange handler whether the script tag was really loaded without problems.

Since IE represents an unfortunately large component of deviantART’s users, half-working failure detection isn’t going to cut it. Especially since all the developers mainly use Firefox/Safari, and wouldn’t expect IE to behave differently.

So for now I’m going with verifying that the script tag loaded something, and says it’s complete. I’ll keep my eyes out for a way to work around IE…

The only real change is that it now allows for multiple instances of the widget. So you can have one showing the ‘food’ tag, and the other showing the ‘yodeling’ tag, say.

When you use the .innerHTML property to add an element to the DOM, IE will fire an “unknown runtime error” if that element is incorrectly nested. So trying to place a <div> inside a <p> (as was the case in the bug report) will error very unhelpfully.

Surprising behavior.

Anyway, this led to the release of maphilight 1.1.1. (Which also includes an official minified version of the file, for convenience’s sake.)

The Automattic example widget came close, but was a bit lacking on the customization front.

del.icio.us for WordPress also came close, but I disagree with having your server fetch the RSS feed, instead of using the perfectly good JSON API.

So I took the Automattic widget, hacked some extra features into it, made it configurable, and you can now see it in my sidebar. Well, footer currently. It’s a theme thing.

If you want it yourself, here’s the link: del.icio.us plus

Edit on 2008-03-27: This is now in the wordpress.org plugins repository.
Edit on 2008-04-16: Version 1.1 released, granting multiple widget instances.

I just released maphilight, a jQuery plugin that turns image maps into wonderful graphical masterpieces.

Image maps aren’t so popular any more, for some strange reason. So a quick definition: an imagemap is an <img> with the usemap attribute, pointing to a <map> that describes polygons that link places within that image.

This sprung from me wanting to display pretty highlighting of countries on a map, but not wanting to mess with flash for it. It involves enough annoying fiddling with <canvas> (and VML, because IE is in the stone age) that I feel I’m saving other people a decent amount of work by releasing it.

Simple demo
Pretty demo using a world map
Documentation
Download (requires jQuery)

(Tools like “ HTML-Image map Creator WYSIWYG” might be handy if you want to make image maps yourself.)

However, I ran into a problem when using it in a project. The documentation and the functionality don’t quite line up.

It has an option, sortForce, which its documentation says you can use to “add an additional forced sort that will be appended to the dynamic selections by the user”. This is a handy concept — it lets you, say, keep records ordered by name, regardless of which other criteria the user chooses to sort by.

The problem is that it actually prepends the sort to the user’s selection, which means that the user is restricted to sorting within the forced sort. (This is also a potentially useful tool; it’s just not what the documentation indicates.)

So I wrote up a patch that fixes this, along with a few other niggling issues with sortForce. (Its interaction with the user sorting by multiple columns, and it locking the forced-sort column in one sort direction.) To preserve backwards-compatibility I added a new option, sortAppend, to provide the documented behavior.

I also submitted the patch to the maintainer, so hopefully it can get incorporated.

2008-08-27: My patch was incorporated as of version 2.0.2, so it’s all good.
2009-03-17: But bits of it weren’t applied, so it can’t be said to have been fixed. Oh well. I’ll resubmit.

Naturally I thought to myself “aha, there must be an XML data feed somewhere in that!” Some light flash-decompilation later, I discovered that I was right.

I then seized on this as a learning opportunity, and wrote a much better viewer, in boring old JavaScript. Why is it better? Because it doesn’t require Flash, and is not limited to one panel at a time, that’s why.

My Dilbert viewer, can you view it?

Caveats:
1. It’s perfect in Firefox3 and Safari. Sundays aren’t quite right in IE7; the first and last buttons are missing in Opera. All else is untested.
2. For some reason, the widget seems to get different feeds for the last week or two, which means this viewer is a week behind. I suspect user-agent sniffing, but have not yet been motivated to work out what a flash-player’s user-agent is.

Things learned:
1. Cross-domain xmlhttprequest requiring a proxy is a pain, and has no obvious benefit.
2. jQuery is still awesome.
3. Forgetting to take out debug statements that rely on FireBug when uploading is dumb of me.
4. Decompiling these things is complex — the embed code provided loads a .swf, which loads a .swf, which finally loads the actual widget that displays the comics.

Update: I worked out the cause of the weird out-of-sync-ness I observed between the data files I received and the content seen in the official widget. The lesson is not to trust the data feed when it tries to tell you which domain to look at; it includes a <Domain> tag, which seems like a perfect complement to the domain-less URLs given in the strip descriptions. However, that domain contains files that are several weeks out of date. So I just hardcoded the “real” URL.

They finally released this stuff to the main Dilbert site, so I just went through and fixed up the viewer to use the appropriate new feed format. Darn changes.