I’ve been working, lately, at making AJAX work within the framework initially laid out at work, ten years ago. It’s not completely trivial, but luckily the framework was flexible enough that I’ve had a fair amount of success. As usual, however, the stumbling block has been integration with Internet Explorer.
On this project, I’m using the Yahoo User Interface (YUI) library to do most of the heavy lifting. Of all the major Javascript frameworks I’ve seen, I think it’s the most flexible. I’ve been happy with it. For one of my XMLHttpRequest calls, I’m just taking the response, which is a list of
This worked, at least, until I went to test it on Internet Explorer 7. The XMLHttpRequest call succeeds, but for some reason my select boxes just went empty. Using the IE Developers Toolbar, I could see that the DOM was malformed, the initial opening
So, I turn to Google, and search for “Internet Explorer Select innerHTML” when what should the first result be? But a Microsoft Knowledge Base Article outlining the problem. And dated 2003. Why Microsoft hasn’t managed to fix this in 4 years and dozens of patches and a major release later, I’ll never know. But at least they posted a work around.
Building the select element, and doing an outerHMTL set was going to be a pain, but I could deal with that. Until it didn’t work. That’s right, the suggested work around from 2003 doesn’t work in IE7. Fantastic.
Now, I have no choice but to write something that dumps XML or JSON, and parse it out at the client, which adds complexity, and takes more time. This probably wouldn’t irritate me so much, if the bug wasn’t so old, it didn’t seem to trivial to fix, and the situation hadn’t worsened in the last four years.
This sort of thing is probably what irritates me the most about IE’s prevalence. I know of no web developers that do their initial testing in IE. Everyone I know uses Firefox or Safari (mostly Firefox, by far) to do their initial building, and then port it over to IE. It just goes to show how lousy IE really is, that it, being the most widely used browser, isn’t the primary development environment for web applications.
It would be like if Windows application were all developed in Linux and then grudgingly ported over to Windows. Of course, I tend to do this anyway, since it’s far more pleasant for me to work in Linux, but I know that I’m the exception to that rule by far.
Unfortunately, us web developers have dug this hole, and we’re going to continue to drown in it. By catering to poor standard’s compliance throughout the browser wars and into today, we’ve told the browser companies that it’s okay to not follow the standards, we’ll deal with it on our end. Had we taken a stand when IE was the new, broken-ass kid on the block, and refused to bend over backwards for IE, I bet it would have been a far better product. As it stands, Microsoft has no incentive to fix these sorts of bugs, as we’ve told Microsoft that we’ll take care of it.
I’d love to have the application flake out and not always work right on IE. I really would, but unfortunately, the majority of our users are IE, and it’s not worth the calls we’d get if we went that route. Today I’m having to bite my lip and implement code far more complex and error prone than I’d intended, but I’m left with no choice from Microsoft.
I wonder if there is a relatively easy way to force IE users to use postbacks, while Safari/Firefox users can use the AJAX stuff… I wonder if it’s really worth implementing…