Top 10 reasons why I hate Internet Explorer (Warning: more ranting by me!)

As a web developer, there are a few mantras that I live by. The first, since it's not my primary job, is that web development needs to be fun. The second is that virtually anything is possible on the web, given enough time to figure it out. And the third is that any and all incarnations of Microsoft Internet Explorer are the scourge of the world.

Now, I understand that this third mantra seems a little harsh, so let me try to soften tone a little bit. I hate Internet Explorer. And after spending the last two days trying to make something that should have been simple work - again - in Internet Explorer, I thought it was finally time to tell the world why. Well, the top ten reasons why, anyway. So, here they are, in true Letterman style.

10. With a rapidly dwindling share of the browser market, Microsoft's attitude that the internet is Internet Explorer (or, rather, that IE is the internet) is the epitome of hubris. No product is the penultimate, much less Internet Explorer.
    


9. Standards? We don't need no stinking standards! We are the standard! Since Internet Explorer 6, Microsoft has included a "standards" mode in IE that was supposed to conform to W3C HTML standards. Strangely enough, though, neither IE6's nor IE7's rendition of these standards - yes, we'll talk about that in a moment - came even close to actually fulfilling the standards by which every other browser on the planet lives.
   


8. 6 years. Yes, after feverishly developing the thing in the late 90's so Microsoft could crush Netscape and lay siege to the entire browser market, that's how long IE6 sat gathering cobwebs before Microsoft decided to dust off their browser, give it a facelift, and release IE7. In 6 years, we went from Windows ME to Windows XP, and very nearly Windows Vista. There were three versions (maybe more) of Microsoft Office released, and broadband went from a tiny sliver of connections to the majority. 6 years. In most industries, 6 years without a new product mean you are out of business.
   


7. Convoluted Javascript namespace. In the 90's, it was supposed to make life easier. But that was before the dawn of the broadband era and complex, web-based applications. Back then, it was quick and easy for developers to be able to reference HTML elements directly by their id attribute, but now it is increasingly common to need variables with the same name as some of your attributes. How many times have I built an application, only to find out that there was something else on the page that conflicted with what I just wrote! (For the record, I always preferred the Netscape DOM that required you to walk down level by level. The document.getElementById method is a great shortcut for this that still doesn't confuse the namespace).
   


6. ActiveX. What in the world is that? Things that should have been in the browser in the first place, but Microsoft thought it needed to put its own name on? And while we're on the subject of ActiveX, what is up with Msxml2.XMLHTTP and Microsoft.XMLHTTP? Couldn't they make up their mind? I guess "breaking the internet" is bad unless it means you get to put your whole name on it?
   


5. Crash. Back in the NS4 days, Internet Explorer seemed relatively stable. But relatively is still not stable! Indeed, Javascript should not be able to crash your browser!
   


4. Windows. I understand that Microsoft argued in its antitrust suits that the web browser would become an integral part of the operating system, but they clearly didn't believe it since they never developed their web browser with their operating system. To restrict an application to one particular OS is ridiculous. When that OS is Windows - think Vista - it's downright insane.
   


3. Horrifying scripting environment. There are at least three components here. First is the fact that some code that runs in one version explodes disastrously in another. Second is the utter lack of real developer tools. Yes, I know there are some third party resources out there, but compare them to the likes of Firefox's error console (not even Firebug, which blows them all out of the water), Safari's Developer menu, Opera's developer plugin, and you'll find IE wanting every time. And then you add in the insanely unintuitive nature and structure of things. For instance, an acquaintance of mine (who by the way runs http://www.mibbit.com - a great web-based IRC client that provides translation on-the-fly using the Google AJAX Language API) noted today that the recommended method for obtaining the position of the cursor in a text box is to (1) insert some unique text, (2) grab the value of the input, (3) find the index of the unique test, and (4) remove the unique text. What? Add in a totally whacked event model, an irritating tendency to do things you didn't tell it to do (e.g., resizing an element that you didn't even touch), and an inexplicable penchant for not doing things you did tell it to do, and you end up with nothing less than a web developer's nightmare.
   


2. 3 totally different rendering modes, at least. No, that's not a typo. Internet Explorer 6 has two rendering modes: quirks and standard. You have to force it into standards mode with a doctype declaration. Internet Explorer 7 has its own quirks mode (which we'll consider the same as IE6's), plus IE6-esque mode (where it rendered standards-based pages as IE6 would) and then its own standards mode. As if that isn't confusing enough, the last version of IE:Mac, which still persists in some dark, dark corners of the world, had another totally different rendering model. And now, the news is that IE8 is coming with two different "standards" modes - one to conform to IE7, and the other that will be closer to the real W3C standards (but still not there!). I guess, for Microsoft, "standards" is an oxymoron. Unless, of course, the standard is non-standard.
   


1. It could probably go under horrifying scripting environment, but this is so criminal that it deserves its own spot - at the top of the list, no less. Cryptic and/or patently insufficient error messages. How many times have I been working on a page only to be stopped cold by a scripting error in IE. The only message I get from IE, though, boils down to, "You have an error on line xxx." The box does provide a file name, but it is always filled with that of the page itself, regardless of where the error actually fired. This is a huge problem when modern sites can often include 5, 10, 20, even 50 Javascript files, all of which may have a line xxx. It does, on occasion, include an error message but that can range from something as unenlightening as "Object expected" to something as absolutely maddening as, "Unable to complete due to error 80020003." And it's even worse when you realize - about the first time you try to debug something with all of this information - that even that line number you received was wrong. This isn't a once-in-awhile type thing like it is with other browsers and debugging environments; it's a more-often-than-not type of thing. In my world, this one problem alone contributes to more time (and hair) lost than just about any other hurdle I have to deal with.
   

So there you have it. The top ten reasons why I hate Microsoft Internet Exploder Explorer. If you're a developer, I'm sure you've found your own reasons to hate it, too. In fact, even my non-developer friends are realizing that it's a terrible, terrible browser, including some that are otherwise staunchly pro-Microsoft.

This list is absolutely not exhaustive. If I had more time (and you had more patience), I would include things like filters, horrifying inadequacies in CSS rendering, and a number of others. But for now, this will have to do. And the adventure continues...

What I learned on today's adventure:

1. Internet Explorer stinks
2. Any computer infested with Internet Explorer should be hauled off to the dump
3. Development is a nightmare in Internet Explorer
4. Internet Explorer's market share can't go down fast enough
   

How to get all the results available from your Google AJAX Search API application

If you haven't heard of it yet, the Google AJAX Search API is a pretty nifty little doo-dad. Basically, it allows you to add Google search functionality without having to divert visitors from your site, hack the Google infrastructure, or even deviate from your own formatting rules. It works like this: you build a control of some sort that will process user input; form a request URL; and get information, including web, local, news, video, image, blog, book, and even patent search results via JSONP. Pretty slick, if you ask me, but one of the questions I often receive regarding the API goes something like this: "It's a cool concept, but how can I get more results?" You see, using it, you can currently only get up to 64 results (less for local and blog searches), and you can only retrieve those in blocks of 8.

So for today's adventure, I thought we could explore getting as many results as we possibly can from the Google AJAX Search API. But right off the bat, there is a disclaimer: I'm not going to tell you how to get around the limit of total results you can retrieve. The AJAX Search API is designed to provide rudimentary search functionality for the users of your website or other application, not for SEO, data mining, or even deep searching. And it does that intended task admirably. To try to bypass the total results limit is a violation of the service's Terms of Use and, I believe, generally unnecessary when using the API as intended.

Rather, what we're going to talk about is getting all the results that they will let us get in one fell swoop.

So, how do we do it? Well, first things first; we set up our searcher as normal. Because the default google.search.SearchControl is obfuscated, we're going to have to use a RAW searcher. If you don't know how to do this, you'll want to check out the documentation at http://code.google.com/apis/ajaxsearch/documentation/.

Once that's done, there are two methods of the searcher object that we're going to take advantage of: .setSearchCompleteCallback() and .gotoPage(). Details for both of these methods are provided in the class reference.

Essentially, the process, broken down into its component steps, is going to go like this.

1. We set up the searcher's completion callback
2. We execute a search query
3. The query returns, executes the completion callback
4. The completion callback checks to see if there are more results
5. If there are more results to get, calls gotoPage(...);
6. Otherwise, finish processing the results

So, are you ready for this? Here's the code, commented up so you can see what's going on.

// Initialize the searcher object, in this case a WebSearch.
window.gs = new google.search.WebSearch();
gs.setResultSetSize(google.search.Search.LARGE_RESULTSET);

// Set the search complete callback. Notice that we're using the searcher itself as the context. This is going to allow us to use this in the callback to refer to the searcher.
gs.setSearchCompleteCallback(gs,function(){

// Set a handle to the cursor object that we're going to use repeatedly
var cursor = this.cursor;

// Create a new property on the searcher that we can stash results into so they don't disappear when we go to the next page.
if(!this.allResults || cursor.currentPageIndex==0){this.allResults = [];}

// Add the new results to the other results
this.allResults = this.allResults.concat(this.results);

// Check to see if the searcher actually has a cursor object and, if so, if we're on the last page of results. If not...
if (cursor && cursor.pages.length>cursor.currentPageIndex+1){

// Go to the next page.
this.gotoPage(cursor.currentPageIndex+1);

// Else, if there is no cursor object or we're on the last page...
} else {

// Loop through the results and...
for(var i=0; i<this.allResults.length; i++){
var result = this.allResults[i];


// Plug them into the document where we want them.
document.body.appendChild(result.html.cloneNode(1));
}
}
});


Check it out in action here.

And there you have it! All 64 results from a Google AJAX Search API WebSearch, in one shot.

What I learned on today's adventure:

1. I can use the Google AJAX Search API to get up to 64 search results for use on my site or in my application.
2. How to use searcher.setSearchCompleteCallback and searcher.gotoPage to get all available results in one fell swoop.