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
<img/> elements, but that’s about it.
“Microsoft is getting Internet Explorer back on track.”
Netscape Navigator 4
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
mySecondLayerId that is nested within a layer with an
myLayerId. Yes, developers had to walk down the layer "tree" in order to access nested layers.
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
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.
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.
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.
“Microsoft changed the face of not only front-end development, but web development as a whole…”
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
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
In addition to loading elements as objects, IE4’s DOM represented an element’s attributes as properties of the element object. For example, the
style properties mapped directly to an element’s
style attributes, respectively. This design became standard.
Microsoft invented the
innerHTML property to get or set an element’s content. Unlike Netscape’s
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
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
styleproperty, 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.
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.
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
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.”
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.
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.