The innovation balance

There’s lots of people out there really pushing the envelope of what can be done with the DOM and CSS. You all know this. But, at some point, there comes a time when you hit a wall, and that wall is named Internet Explorer.

This wasn’t always the case: to get to the Internet Explorer wall you now step over the crumbling ruins of the wall that was there before. If you pick up an aged, weathered brick from that wall you can just about see the words “Netscape 4” painted on it. But that wall’s just an old pile of stones that everyone ignores, these days. Internet Explorer is the new Netscape 4.

The concern here is: do you let that hold you back? I mean, l00k, d00d! Firef0x haz these k-rAd new t00ls! IE is teh sux0r! Kill the M$!

Er, perhaps not. That’s a serious question, though; at what point should we abandon IE support in order to deliver better interfaces to Firefox users?

There’s a pretty reasonable argument that the answer to that question is: never. Don’t do FF-only things. Waving the banner of “standards compliance” and saying “well, it’s the IE development team’s fault for not bothering to implement all of CSS” is pure sophistry, and you know it. Web developers were castigated, and rightly so, for using Internet Explorer-specific technologies. Anyone remember HTML+TIME? Javascript expressions in CSS? Those of you sneering now: what about innerHTML? Contenteditable? XMLHTTPRequest? Not everything that is non-standard is necessarily something to be thrown away.

There’s a small, but growing, class of DOM manipulations that are being released as working in Firefox (and possibly Safari and Opera) but not in IE. Take two very neat indeed hacks I’ve seen recently: Brad Fitzpatrick’s Ajax-based shared whiteboard and Tim Taylor’s drag-and-drop sortable lists. They’re both really neat bits of code, and I hope that their talented authors won’t take exception to me naming them here; they also both don’t work in IE. Now, since DOM manipulation should be something which layers extra usability over an already usable site, one that works entirely without JavaScript turned on (Google, I’m looking at you here, again), this shouldn’t matter…but it does, really. Both authors have, to their credit, acknowledged that their code doesn’t work, and implied that they’re working on that, but we of the standards compliance flags and warcries need to be careful that those cries really were for the standards and not against the Seattle juggernaut.