The Things Internet Explorer Got Right

It’s the browser that everyone loves to hate—sometimes justifiably so. What was once the most innovative browser became the thorn in every front-end developer’s side. Amidst the turmoil and complaints today’s developers throw at Internet Explorer, what’s often not heard is how Microsoft changed the face of not only front-end development, but web development as a whole.

IE’s fall is not an uncommon story; in fact, it’s somewhat the same story as Netscape. The company behind the leading browser grows complacent, the browser stagnates, and a new champion arises. It’s a repetitive cycle, one that Mozilla faces again to some extent (but that’s another story for another time).

IE4’s Influence on the DOM

Prior to the version 4 browsers, JavaScript was primarily used for simple data processing (form validation). As such, web pages were primarily static. While a page could be dynamically generated by server-side applications, the page could not interact with the user. This limitation existed because of the browser’s inadequate Document Object Model (DOM), which is the application programming interface (API) JavaScript developers use to access and manipulate individual elements in the page. The DOM that existed prior to the version 4 browsers is frequently referred to as DOM Level 0. DOM Level 0 implementations allow developers access to <form/>, <a/>, and <img/> elements, but that’s about it.

“Microsoft is getting Internet Explorer back on track.”

Netscape Navigator 4

It wasn’t until Netscape released Navigator 4 (NS4) in mid-1997 that a browser’s DOM allowed web developers to alter a page with JavaScript. The technique of manipulating elements with JavaScript and the DOM was dubbed Dynamic HTML (DHTML). NS4’s DHTML was certainly a step forward, but its proprietary and ill-designed layer-based DOM and limited Cascading Style Sheet (CSS) support restricted developers in what they could actually accomplish.

Accessing Elements

Netscape did not implement a full object model. Aside from DOM Level 0 functionality, the only elements a developer could access were absolutely positioned elements, <layer/> elements, and <ilayer/> elements (the latter two elements were de facto positioned). Each of these types of elements were represented by a Layer object in NS4’s DOM. Netscape designed Layer objects to be very similar to frame (and thus window) objects. Each Layer object had a document property, which basically was another HTML document. Like frames, a Layer object could be nested in another Layer object, making code to access those layers extremely verbose like the following:

var myLayer1 = document.layers["myLayerId"].document.layers["mySecondLayerId"];
// or
var myLayer2 = document.myLayerId.document.mySecondLayerId;

These two lines of code do the same thing: they access the Layer object with an id of mySecondLayerId that is nested within a layer with an id of myLayerId. Yes, developers had to walk down the layer "tree" in order to access nested layers.

Dynamic Content

NS4’s DOM did not allow for the creation, insertion, relocation, and removal of DOM objects, but because each layer exposed a document object, a developer could dynamically change a layer’s content by using the write(), load(), and close() methods. While this gives some extra power to the layer model, it restricted developers in how they could dynamically update a page. New content would have to be written or loaded into a layer, effectively removing the layer’s existing content. Needless to say, most developers avoided content manipulation and instead focused on changing a layer’s style.

Changing Style

Web development using NS4’s DOM was painful and frustrating.

But style in NS4’s DOM was a funny thing. While the browser supported CSS to some degree, Layer objects did not provide an API for developers to directly access a layer’s style attribute like today’s style object. Instead, Layer objects exposed a very limited set of properties that altered a layer’s position, visibility, clipping, and background color/image—nothing else, and the value these properties accepted were also quite limited. For example, the positioning and clipping properties only accepted numeric values; a developer could not specify a unit (such as px, em, pt, etc). An example of such code follows:

var myLayer = document.myLayerId.document.mySubLayerId;
myLayer.top = 10;

Needless to say, web development using NS4’s DOM was painful and frustrating. NS4’s extremely limited DHTML capabilities stem from the limitations of NS4’s rendering engine (it could not reflow the page). But why spend so much time on Netscape’s DOM, especially in an article that’s supposed to be about IE? Had Netscape won the browser war, today’s DOM would be an evolutionary step from the DOM presented by Netscape in NS4. While today’s DOM is a standard put forth by the W3C (and some Netscape ideas are implemented in today’s standard), today’s DOM is heavily influenced by IE4’s DOM.

IE4’s DOM

Just a few months after Netscape released Navigator 4, Microsoft released the fourth version of IE. It, too, included support for DHTML, but Microsoft’s implementation was far different and superior to NS4. IE4 boasted much better CSS support and a more complete object model to access and manipulate elements and content in the page. The effect of IE4’s DOM was far reaching; in fact, a developer can find many similarities between IE4’s DOM and the standard DOM.

Accessing Elements

“Microsoft changed the face of not only front-end development, but web development as a whole…”

IE4’s designers wanted to turn the browser into a platform for Web applications. So they approached IE4’s API like an operating system’s—providing a near complete object model that represented each element (and an element’s attributes) as an object that could be accessed with a scripting language (IE4 supported both JavaScript and VBScript).

In IE4’s DOM, the primary means of accessing a particular element in the page was the proprietary all[] collection, which contained every element in the document. Developers could access elements with a numerical index or by specifying an element’s id or name, like this:

var myElement1 = document.all["myElementId"];
// or
var myElement2 = document.all.myElementId;

Using this code, developers could access the element object with an id of myElementId regardless of where it existed within the page. This is in stark contrast to Netscape’s layer model in which developers could only access layers through the layer’s hierarchy. The functionality of document.all["elementId"] evolved into the standard document.getElementById() method. But this wasn’t the only way a developer could access elements; one could walk the DOM tree and touch each element with the children[] collection and parentElement property—forerunners to the standard childNodes[] and parentNode properties.

In addition to loading elements as objects, IE4’s DOM represented an element’s attributes as properties of the element object. For example, the id, name, and style properties mapped directly to an element’s id, name, and style attributes, respectively. This design became standard.

Dynamic Content

Microsoft invented the innerHTML property.

Like Netscape, Microsoft did not provide a full-fledged API to dynamically add, move, and remove nodes with JavaScript. They did, however, invent the innerHTML property to get or set an element’s content. Unlike Netscape’s Layer object’s write() and load() methods, the innerHTML property was not an all-or-nothing solution to modifying an element’s content; a developer could use innerHTML to completely wipe out, replace, or add to an element’s content. For example, the following code gets an element’s content and modifies it:

var el = document.all.myElementId,
    html = el.innerHTML;

el.innerHTML = html + "Hello, innerHTML";

To this day, the innerHTML property is a cornerstone of DHTML. It is an efficient means to adding large amounts of content to an element. Even though it has never formally been included in any DOM standard, every major browser implements an innerHTML property.

Modifying Style

Microsoft invented several tools and designs that evolved into pieces of the standard DOM, but the work they did with IE4’s style API became standard with very little modification. The key to changing an element’s style in IE4 was the style property, the same property (and syntax) used by developers today.

DHTML changed web development forever. It was, however, IE4’s DOM that pushed the technology (and web development) forward by being the primary influence on the W3C’s DOM Level 1 and 2 specification. IE4 revolutionized web development in 1997, and IE would do so again a few years later.

IE Revolutionizes Ajax

Ajax blew the doors open for web development.

Before Ajax was Ajax, it was called remote scripting, and developers leveraging the power of remote scripting used hidden frames and iframes for client-server communication. A hidden (i)frame usually contained a form that was dynamically filled out and submitted through JavaScript. The server’s response would be another HTML document containing JavaScript that notified the main page that data was received and ready to use. It was crude, but it worked.

There was an alternative, however: a little known gem buried in Microsoft’s MSXML 2.0 library. IE5, released in March 1999, included MSXML 2.0, and developers found a component called XMLHttp (the actual interface name was IXMLHTTPRequest). Its name is misleading, as the XMLHttp object functions more like a simple HTTP client than anything else. Not only could developers send requests with the object, but they could monitor the requests’s status and retrieve the server’s response.

Naturally, XMLHttp began to replace the hidden (i)frame technique for client-server communication. A couple of years later, Mozilla created their own object, modeled after Microsoft’s XMLHttp, and called it XMLHttpRequest. Apple followed suit with their XMLHttpRequest object in 2004, and Opera implemented the object in 2005.

Despite its growing interest, the popularity of XMLHttp/XMLHttpRequest (collectively known as XHR here on out) didn’t explode until 2005 when Jesse James Garrett published his article, “Ajax: a New Approach to Web Applications.”

Ajax blew the doors open for web development, and at the forefront was JavaScript, XHR, and DHTML—two of which were Microsoft’s inventions. So what happened? What caused a browser that literally changed how web developers write web applications to become the bane of the modern Web?

Internet Explorer’s Fall

By 2003, Internet Explorer’s total market share was around 95%; Microsoft officially won the browser war. With no real competition in the Web space, Microsoft shifted their focus from the browser to .NET. This is confirmed by quotes from many Microsoft employees, but the most telling is from a CNET article entitled “Will Ajax help Google clean up?” In it, Charles Fitzgerald, Microsoft’s general manager for platform technologies, was quoted as saying:

“It’s a little depressing that developers are just now wrapping their heads around these things we shipped in the late 20th century [ed: DHTML and Ajax], but XAML is in a whole other class. This other stuff is very kludgy, very hard to debug. We’ve seen some pretty impressive hacks, but if you look at what XAML starts to solve, it’s a major, major step up.”

So in May 2003, Microsoft announced that IE would no longer be released separately from Windows (the excellent IE5 for Mac was also canned). The browser would still be developed as part of the evolving Windows operating system, but Microsoft would not release any stand-alone versions of IE. They were betting primarily on ClickOnce, a technology that allows developers to write conventional applications (using .NET of course) and distribute them via the Web.

But the Web continued to evolve in the path Microsoft originally set with IE4 and IE5, and Microsoft started to lose market share to Netscape’s heir: Firefox. Developers were writing web applications that lived in the browser, not in conventional applications via ClickOnce. That forced Microsoft to pick up IE, dust it off, and begin releasing stand-alone versions again.

Microsoft Continues to Innovate

IE9, includes much better standards support across the board.

The next two versions, 7 and 8, were largely evolutionary. IE7 contained a variety of bug fixes, the XMLHttpRequest identifier (although it still created an XMLHttp object from the MSXML library), and improvements to the UI and security.

IE8 was largely more of the same, except it sandboxed each tab—a feature that Google also implemented in Chrome (Microsoft announced it first). It isolates each tab in its own process, increasing security and stability. Sandboxing is becoming standard in today’s browsers (Firefox still lacks the capability), and it’s also moving into the realm of add-ons and plug-ins.

Microsoft is getting Internet Explorer back on track.

The latest version, IE9, includes much better standards support across the board, but it also innovates with its new JIT-compiling JavaScript engine (which uses a separate CPU core if available and can access the GPU) and its hardware-accelerated rendering engine. While JIT-compiling JavaScript engines are not new, IE9’s ability to offload compilation onto a separate core in parallel to the page rendering is an accomplishment that will spur on much needed performance for web applications. Its hardware-acceleration abilities proved useful when debuted, and now Firefox and Chrome offer hardware-acceleration to some extent.

There is no denying that Internet Explorer has caused headaches for web developers. The five year lull between IE6 and IE7 caused Microsoft to fall way behind the competition, making front-end development less than ideal. But Microsoft is getting Internet Explorer back on track. They shaped web development to what it is today; here’s hoping they do so again.

The next version of Internet Explorer, version 9, is scheduled to be officially released March 14th, 2011.