The innovations of Internet Explorer

Long before Internet Explorer became the browser everyone loves to hate, it was the driving force of innovation on the Internet. Sometimes it’s hard to remember all of the good that Internet Explorer did before Internet Explorer 6 became the scourge of web developers everywhere. Believe it or not, Internet Explorer 4-6 is heavily responsible for web development as we know it today. A number of proprietary features became de facto standards and then official standards with some ending up in the HTML5 specification. It may be hard to believe that Internet Explorer is actually to thank for a lot of the features that we take for granted today, but a quick walk through history shows that it’s true.

DOM

If Internet Explorer is a browser that everyone loves to hate, the Document Object Model (DOM) is the API that everyone loves to hate. You can call the DOM overly verbose, ill-suited for JavaScript, and somewhat nonsensical, and you would be correct on all counts. However, the DOM gives developers access to every part of a webpage through JavaScript. There was a time when you could only access certain elements on the page through JavaScript. Internet Explorer 3 and Netscape 3 only allowed programmatic access to form elements, images, and links. Netscape 4 improved the situation by expanding programmatic access to the proprietary <layer> element via document.layers. Internet Explorer 4 improve the situation even further by allowing programmatic access of every element on the page via document.all

In many regards, document.all was the very first version of document.getElementById(). You still used an element’s ID to access it through document.all, such as document.all.myDiv or document.all["myDiv"]. The primary difference was that Internet Explorer used a collection instead of the function, which matched all other access methods at the time such as document.images and document.forms.

Internet Explorer 4 was also the first browser to introduce the ability to get a list of elements by tag name via document.all.tags(). For all intents and purposes, this was the first version of document.getElementsByTagName() and worked the exact same way. If you want to get all <div> elements, you would use document.all.tags("div"). Even in Internet Explorer 9, this method still exists and is just an alias for document.getElementsByTagName().

Internet Explorer 4 also introduced us to perhaps the most popular proprietary DOM extension of all time: innerHTML. It seems that the folks at Microsoft realized what a pain it would be to build up a DOM programmatically and afforded us this shortcut, along with outerHTML. Both of which proved to be so useful, they were standardized in HTML51. The companion APIs dealing with plain text, innerText and outerText, also proved influential enough that DOM Level 3 introduced textContent2, which acts in a similar manner to innerText.

Along the same lines, Internet Explorer 4 introduced insertAdjacentHTML(), yet another way of inserting HTML text into a document. This one took a little longer, but it was also codified in HTML53 and is now widely supported by browsers.

Events

In the beginning, there was no event system for JavaScript. Both Netscape and Microsoft took a stab at it and each came up with different models. Netscape brought us event capturing, the idea that an event is first delivered to the window, then the document, and so on until finally reaching the intended target. Netscape browsers prior to version 6 supported only event capturing.

Microsoft took the opposite approach and came up with event bubbling. They believed that the event should begin at the actual target and then fire on the parents and so on up to the document. Internet Explorer prior to version 9 only supported event bubbling. Although the official DOM events specification evolves to include both event capturing and event bubbling, most web developers use event bubbling exclusively, with event capturing being saved for a few workarounds and tricks buried deep down inside of JavaScript libraries.

In addition to creating event bubbling, Microsoft also created a bunch of additional events that eventually became standardized:

  • contextmenu – fires when you use the secondary mouse button on an element. First appeared in Internet Explorer 5 and later codified as part of HTML54. Now supported in all major desktop browsers.
  • beforeunload – fires before the unload event and allows you to block unloading of the page. Originally introduced in Internet Explorer 4 and now part of HTML54. Also supported in all major desktop browsers.
  • mousewheel – fires when the mouse wheel (or similar device) is used. The first browser to support this event was Internet Explorer 6. Just like the others, it’s now part of HTML54. The only major desktop browser to not support this event is Firefox (which does support an alternative DOMMouseScroll event).
  • mouseenter – a non-bubbling version of mouseover, introduced by Microsoft in Internet Explorer 5 to help combat the troubles with using mouseover. This event became formalized in DOM Level 3 Events5. Also supported in Firefox and Opera, but not in Safari or Chrome (yet?).
  • mouseleave – a non-bubbling version of mouseout to match mouseenter. Introduced in Internet Explorer 5 and also now standardized in DOM Level 3 Events6. Same support level as mouseenter.
  • focusin – a bubbling version of focus to help more easily manage focus on a page. Originally introduced in Internet Explorer 6 and now part of DOM Level 3 Events7. Not currently well supported, though Firefox has a bug opened for its implementation.
  • focusout – a bubbling version of blur to help more easily manage focus on a page. Originally introduced in Internet Explorer 6 and now part of DOM Level 3 Events8. As with focusin, not well supported yet but Firefox is close.

Frames were initially introduced by Netscape Navigator 2 as a proprietary feature. This included <frameset>, <frame>, and <noframes>. The idea behind this feature was pretty simple: at the time, everyone was using modems and roundtrips to the server were quite expensive. The main use case was to provide one frame with navigational elements that would only be loaded once, and another frame that could be controlled by the navigation and changed separately. Saving server render time and data transfer by having navigation as a separate page was a huge win at the time.

Internet Explorer 3 supported frames as well, since they were becoming quite popular on the web. However, Microsoft added its own proprietary tag to that functionality: <iframe>. The basic idea behind this element was to embed a page within another page. Whereas Netscape’s implementation required you to create three pages to have static navigation (the navigation page, the content page, and the frameset page), you could create the same functionality in Internet Explorer using only two pages (the primary page including navigation, and the content page within the <iframe>). Initially, this was one of the major battlegrounds between Internet Explorer and Netscape Navigator.

The <iframe> started to become more popular because it was less work than creating framesets. Netscape countered by introducing <ilayer> in version 4, which had very similar features to <iframe>. Of course, the <iframe> won out and is now an important part of web development. Both Netscape’s frames and Microsoft’s <iframe> were standardized in HTML 4, but Netscape’s frames were later obsoleted (deprecated) in HTML5.

XML and Ajax

Although XML isn’t used nearly as much in the web today as many thought it would be, Internet Explorer also led the way with XML support. It was the first browser to support client-side XML parsing and XSLT transformation in JavaScript. Unfortunately, it did so through ActiveX objects representing XML documents and XSLT processors. The folks at Mozilla clearly thought there was something there because they invented similar functionality in the form of DOMParser, XMLSerializer, and XSLTProcessor. The first two are now part of HTML59. Although the standards-based JavaScript XML handling is quite different than Internet Explorer’s version, it was undoubtedly influenced by IE.

The client-side XML handling was all part of Internet Explorer’s implementation of XMLHttpRequest, first introduced as an ActiveX object in Internet Explorer 5. The idea was to enable retrieval of XML documents from the server in a webpage and allow JavaScript to manipulate that XML as a DOM. Internet Explorer’s version requires you to use new ActiveXObject("MSXML2.XMLHttp"), also making it reliant upon version strings and making developers jump through hoops to test and use the most recent version. Once again, Firefox came along and cleaned up the mess up by creating a then-proprietary XMLHttpRequest object that duplicated the interface of Internet Explorer’s version exactly. Other browsers then copied Firefox’s implementation, ultimately leading to Internet Explorer 7 creating an ActiveX-free version as well. Of course, XMLHttpRequest was the driving force behind the Ajax revolution that got everybody excited about JavaScript.

CSS

When you think of CSS, you probably don’t think much about Internet Explorer. After all, it’s the one that tends to lag behind in CSS support (at least up to Internet Explorer 10). However, Internet Explorer 3 was the first browser to implement CSS. At the time, Netscape was pursuing an alternate proposal, JavaScript Style Sheets (JSSS)10. As the name suggested, this proposal used JavaScript to define stylistic information about the page. Netscape 4 introduced JSSS and CSS, a full version behind Internet Explorer. The CSS implementation was less than stellar, often translating styles into JSSS in order to apply them properly11. That also meant that if JavaScript was disabled, CSS didn’t work in Netscape 4.

While Internet Explorer’s implementation of CSS was limited to font family, font size, colors, backgrounds, and margins, the implementation was solid and usable. Meanwhile, Netscape 4′s implementation was buggy and hard to work with. Yes, in some small way, Internet Explorer led to the success of CSS.

The box model, an important foundation of CSS, was heavily influenced by Internet Explorer. Their first implementation in Internet Explorer 5 interpreted width and height to mean that the element should be that size in total, including padding and border. This came to be known as border-box sizing. The W3C decided that the appropriate box sizing method was content-box, where width and height specified only the size of the box in which the content lived so that padding and border added size to the element. While Internet Explorer switched its standards mode to use the content-box approach to match the standard, Internet Explorer 8 introduced the box-sizing property as a way for developers to switch back to the border-box model. Of course, box-sizing was standardized in CSS312 and some, most notably Paul Irish, recommend that you should change your default box-sizing to border-box13.

Internet Explorer also brought us other CSS innovations that ended up being standardized:

  • text-overflow – used to show ellipses when text is larger than its container. First appeared in Internet Explorer 6 and standardized in CSS314. Now supported in all major browsers.
  • overflow-x and overflow-y – allows you to control overflow in two separate directions of the container. This property first appeared in Internet Explorer 5 and later was formalized in CSS315. Now supported in all major browsers.
  • word-break – used to specify line breaking rules between words. Originally in Internet Explorer 5.5 and now standardized in CSS316. Supported in all major browsers except Opera.
  • word-wrap – specifies whether the browser should break lines in the middle of words are not. First created for Internet Explorer 5.5 and now standardized in CSS3 as overflow-wrap17, although all major browsers support it as word-wrap.

Additionally, many of the new CSS3 visual effects have Internet Explorer to thank for laying the groundwork. Internet Explorer 4 introduced the proprietary filter property making it the first browser capable of:

  • Generating gradients from CSS instructions (CSS3: gradients)
  • Creating semitransparent elements with an alpha filter (CSS3: opacity and RGBA)
  • Rotating an element an arbitrary number of degrees (CSS3: transform with rotate())
  • Applying a drop shadow to an element (CSS3: box-shadow)
  • Applying a matrix transform to an element (CSS3: transform with matrix())

Additionally, Internet Explorer 4 had a feature called transitions, which allowed you to create some basic animation on the page using filters. The transitions were mostly based on the transitions commonly available in PowerPoint at the time, such as fading in or out, checkerboard, and so on18.

All of these capabilities are featured in CSS3 in one way or another. It’s pretty amazing that Internet Explorer 4, released in 1997, had all of these capabilities and we are now just starting to get the same capabilities in other browsers.

Other HTML5 contributions

There is a lot of HTML5 that comes directly out of Internet Explorer and the APIs introduced. Here are some that have not yet been mentioned in this post:

  • Drag and Drop – one of the coolest parts of HTML5 is the definition of native drag-and-drop19. This API originated in Internet Explorer 5 and has been described, with very few changes, in HTML5. The main difference is the addition of the draggable attribute to mark arbitrary elements as draggable (Internet Explorer used a JavaScript call, element.dragDrop() to do this). Other than that, the API closely mirrors the original and is now supported in all major desktop browsers.
  • Clipboard Access – now split out from HTML5 into its own spec20, grants the browser access to the clipboard in certain situations. This API originally appeared in Internet Explorer 6 and was then copied by Safari, who moved clipboardData off of the window object and onto the event object for clipboard events. Safari’s change was kept as part of the HTML5 version and clipboard access is now available in all major desktop browsers except for Opera.
  • Rich Text Editing – rich text editing using designMode was introduced in Internet Explorer 4 because Microsoft wanted a better text editing experience for Hotmail users. Later, Internet Explorer 5.5 introduced contentEditable As a lighter weight way of doing rich text editing. Along with both of these came the dreaded execCommand() method and its associated methods. For better or worse, this API for rich text editing was standardized in HTML521 and is currently supported in all major desktop browsers as well as Mobile Safari and the Android browser.

Conclusion

While it’s easy and popular to poke at Internet Explorer, in reality, we wouldn’t have the web as we know it today if not for its contributions. Where would the web be without XMLHttpRequest and innerHTML? Those were the very catalysts for the Ajax revolution of web applications, upon which a lot of the new capabilities have been built. It seems funny to look back at the browser that has become a “bad guy” of the Internet and see that we wouldn’t be where we are today without it.

Yes, Internet Explorer had its flaws, but for most of the history of the Internet it was the browser that was pushing technology forward. Now that were in a period with massive browser competition and innovation, it’s easy to forget where we all came from. So the next time you run into people who work on Internet Explorer, instead of hurling insults and tomatoes, say thanks for helping to make the Internet what it is today and for making web developers one of the most important jobs in the world.

Update (23-August-2012): Added mention of box-sizing per Sergio’s comment. Added mention of <iframe> per Paul’s comment.

Update (10-September-2012): Added mention of Internet Explorer 3 support for margins based on Chris’ comment.

Translations

  1. innerHTML in HTML5
  2. textContent in DOM Level 3
  3. insertAdjacentHTML() in HTML5
  4. Event Handlers on Elements (HTML5)
  5. mouseenter (DOM Level 3 Events)
  6. mouseleave (DOM Level 3 Events)
  7. focusin (DOM Level 3 Events)
  8. focusout (DOM Level 3 Events)
  9. DOMParser interface (HTML5)
  10. JavaScript Style Sheets (Wikipedia)
  11. The CSS Saga by Håkon Wium Lie and Bert Bos
  12. box-sizing property (CSS3 UI)
  13. * { box-sizing: border-box } FTW (Paul Irish)
  14. text-overflow property (CSS3 UI)
  15. overflow-x and overflow-y (CSS3 Box)
  16. word-break (CSS3 Text)
  17. overflow-wrap/word-wrap (CSS3 Text)
  18. Introduction to Filters and Transitions (MSDN)
  19. Drag and Drop (HTML5)
  20. Clipboard API and Events (HTML5)
  21. User Interaction – Editing (HTML5)

Comments

  1. Gunnar Bittersmann

    Another addition to the list of CSS properties: text-align-last
    Supported in IE since way back when, finally in Firefox (still prefixed), but still lacking support in Webkits and Opera.

  2. Jeremy McPeak

    I've always said IE 4 is the best browser in the history of the Web. While some would say the DOM sucks, I say the DOM could (and would have) suck worse.

  3. Adam

    Great article. How easy it is to forget. We can learn from what got accepted how to design standards that will stick.

    Typo in first paragraph: thank not think

  4. Schepp

    On top of that there are IE filters that allow to do...

    ...do what some of the new CSS Filter Effects are finally capable of, namely grayscale, blur and even sepia (IE-filter combined with an IE-filter script). I am working on a polyfilter right now.

    ...do masking which allows you to polyfill CSS Masks (which are currently being spec'ed): the chroma filter and alpha filter with opacity gradients (see the top right graphic here: http://multimediatreff.de/)

    ...do wet floor effects for images using a flipv and an alpha filter with a vertical opacity gradient.

    That BTW a reason why I cry many tears about the fact that IE10 killed off those proprietary filters while not filling all the gaps.

    And finally: Great post of yours! I also queue up in the row of people who cannot hear that moaning about IE anymore. Times change and so do the stars amongst the browsers.

  5. Flavio Tordini

    As a web developer, I was aware about most of IE contributions and still hated IE6 back in the day. I think the hate stemmed not from a lack of innovation by IE in the early years, but rather from the impasse created by Microsoft by not updating its browser for ages. When IE6 lagged behind other browsers it forced web developers to do additional work just for IE6. More work for IE6 meant hate for IE6.

  6. Paul Irish

    Great article. I've spoken about the same sort of thing: https://vimeo.com/28128002#... The talk focuses on the invention of innerHTML but this section hits on IE's other greatest hits:

    The [datasrc] attribute is a worthy addition. It is real databinding built into the browser. In their examples, you hook up an empty table to a .csv file, and now you've got a real datatable, with live sorting provided by the browser.

    The iframe was introduced in IE, back when "frames" had a terrible reputation. But ye olde inline frame proved to be a necessity in the modern web.

    Favicons were IE's invention, who doesn't love those? Sure it's billions of superflous http requests every minute, but it sure makes our tabs bars easier to navigate.

    Lastly, overflow-x got covered though the longhand background-position-x/y also debuted as IE's invention.

  7. Yusuf

    Luckily it was Microsoft who did this. Cheers for not patenting it all and allowing others to build on top of it. (Any Apple fans here!)

  8. Jon

    Thanks for writing this. I think this is an important post with all of the ie-bashing that goes around. I'm not saying that the bashing isn't deserved but remembering their innovations is important.

  9. Ryan

    Great read man, thank you. I fall victim to poking at IE all too often, and it is easy to forget the foundation it built on the road to the current web.

  10. Yuhong Bao

    IE was not the first browser to support CSS. Arena and emacs-w3 did it before IE.

  11. FremyCompany

    You forgot the amazing HTML Components!

  12. Haha had a good read on this one, IE has played a massive part in the web, shame the latest ie doesn't have as much html5 support as say chrome or firefox!

    Alex.

  13. Sérgio Lopes

    Another great addition is box-sizing:border-box. I know IE old box model was a big problem for portability, but it was visionary. W3C's box model is not intuitive. CSS3 box-sizing is a great property.

  14. megasteve4

    So do you work on internet explorer then - its ok you can tell us ;-)

    But seriously - informative article - its a shame despite apparently being the catalyst for a lot of good / current standards they have still lost their way... But thanks for the well referenced write up.

  15. Matt Lewandowsky

    This was really just a taste of how deep the thanks the modern web owes to IE is. You left out many of the other advances from IE 4, 5, and 5.5, nevermind their experiments with ie:mac. I keep trying to remind people of the shoulders we stand upon in this day of "Web 2.0": IE was essentially "Web 1.5".

    BTW, Yuhong Bao, while technically correct, neither was a mainstream browser. In fact, Arena was never even available on the mainstream desktops. So as for writing CSS that could be used by the masses, we couldn't do that until IE 3 a couple years later. IE didn't become a "threat" on Arena's platforms until 4.0 (and then only through 5... but by then Arena was kaput and not due to IE's competition anyhow). We'll ignore emacs, as editor wars are way off-topic here, but emacs-w3 was arguably less relevant than Arena to the development of CSS. Neither of those browsers really brought a lasting legacy of innovation which the standards are still catching up to almost a decade later, with the features having been used by tens of thousands (conservatively) of developers over the years, as well.

  16. Matt Lewandowsky

    Grumble. Math fail. I meant "two decades later", in my previous comment.

  17. John Hann

    No doubt, Microsoft did some serious innovation in the late 90s. Competition is generally good for industry.

    However, I find a few of your examples of innovation somewhat bizarre.

    document.all

    document.all is a confusing disaster of an API. document.all() vs document.all[] vs document.all. vs document.all.tags(nodeType)... Thank god Netscape and the W3C didn't follow it. This is not innovation.

    CSS filters

    CSS filters were well-known to be an attempt by Microsoft to block Netscape by tying the coolest new features to Windows DirectX. Since Netscape was multi-platform, they had to code to the least common denominator or spend tons more resources to try to achieve parity. IE's filters not only unfairly blocked Netscape, but also helped Microsoft secure their OS monopoly.

    The author(s) of CSS filters didn't even understand what the C in CSS stands for. The filters are composed in a manner that's inconsistent with the cascade. I also fail to see the innovation here.

  18. Nicholas C. Zakas

    @John - As I said, document.all was the precursor to both document.getElementById() and document.getElementsByTagName(). Both of those APIs, while not using the same names, do the exact same thing. It was Internet Explorer that first allowed us such programmatic access to elements on the page.

    Your statement about CSS filters is mostly conjecture. I have a hard time believing that they were designed to block Netscape. Yes, it was a side effect that Netscape couldn't implement those on other operating systems, but suggesting that the primary purpose of filters was anything other than to provide cool visuals on the web first is doing Microsoft a disservice.

    If you're unable to see the innovation in creating complex visual effects using only CSS over 10 years ago, then I'm not sure what you would be impressed with.

  19. IE8 introduced Accelerators which I have been surprised to observe were not mentioned nor have Accelerators gone viral as Accelerators allow highlighting any text in any web page and without leaving that page submitting that text to a Web service that returns a mini-application that runs in a 320x240 popup that cannot be blocked.

  20. Mike Lee

    Great post Nicholas! It's great to see someone with your reputation speak the truth about Microsoft's major contributions to the web world we're all so excited about now.

    I'm really interested in seeing you do a post on how much Microsoft's WSH (Windows Scripting Host) led and influenced JavaScript runtimes like Rhino and now Node.js. WSH exposed a tremendous amount of OS functionality to the scripting world more than a decade ago when most didn't take JavaScript seriously.

    P.S. Microsoft's HTML Applications (HTA) were an awesome precursor to things like AIR and XUL and was introduced in IE 5 back in 1999!

  21. Webstandard-Blog &amp; IE

    IE filters are one way, but they aren't really good for the performance. It would be better to develop CSS properties. We don't need filters to solve problems tof the browser.

  22. Shane Horn

    "You either die a hero or live long enough to see yourself become the villain"

  23. Pankaj Nikam

    Very few people know the actual beauty of IE. Many people follow a monkey convention like if someone hates it, I hate it too. Sometimes people are too focused on the negative aspects rather than focusing on the positive sides which actually help. I also recall the DX-Transforms which are supported in IE which can be somehow mapped to the CSS3 standards. I agree that it is only supported in IE, however now it is a standard. It will surely be supported though not through DX-Transforms, but via CSS3.

    Liked your article. It is nice to know people who really focus on the postive aspects too :)
    Thanks!

  24. Stilgar

    GPU hardware acceleration anyone?

  25. Stilgar

    Oh and also multiprocess browsing (first introduced in IE8 beta 2 several weeks before Chrome was announced)

  26. bruce

    Good stuff.

    It's also important to remember that, before we all hated IE6, we all loved it.

    If you'll forgive the self-link, I wrote something similar "In praise of Internet Explorer 6" http://www.brucelawson.co.u...

  27. Dayv

    I remember starting a project in 1999 to produce a multimedia technical documentation browser. The idea being that it would be a standalone or client server application. For security and protability reasons it was never intended to be a thin client or a web site. There were expensive proprietary engines for doing such things but we discovere that we could harness IE 4 and later 5 DHTML to do the display work better than these proprietary engines. Netscape was just not even a contender. This does mean that we have a lot of legacy code now that we are begining to bring in line with standards, but when there is no standard for what you want to do, you have to use the tools available. I think people sometimes talk of IE as if it was a great blight on the web for years and whilst Microsoft did use some very dirty tactics against Netscape, IE was also in legitimate ways, a much superior browser and people got on using the tools they needed to get the job done while the W3C mused over esoterica and failed to produce pragmatic standards.
    By the time IE6 appeared there was no real competition for IE and Microsoft allowed it to stagnate. Fortunately, there is decent competition driving browser design again, but this is more built on the good innovations of IE than the more trendy opinion of correcting the failings of IE.

  28. webreac

    I was using ncsa mosaic in 1993. I can testify that this whole article is a complete rewrite of the history. The syntax of CSS is a good illustration of how Microsoft has introduced complexity where Netscape was trying to make things uniform. I think the history of browser has given people the real sense of "proprietary software" lock-in. This has probably benefit to the development of open source alternatives (like Chrome, android, ...).
    The compatibility benchmarks available everywhere show that nobody should use a release of IE older that IE10 (IE9 is not as broken as IE7-8, but has a lot of issues).

  29. JohnC

    I've never forgotten what fun it was to write pages for IE4, how much more stuff you could do with a bit of javascript and some brainwork than you could in the Netscape of the day. It's a real shame for Microsoft to have gone from near the forefront of innovation to playing catch-up and spending a fortune on TV advertising for a browser no-one really wants.

    I hope someone at MS reads this and realises how far astray they've gone.

  30. Mr-Yellow

    Finally a voice on this subject which isn't some kind of iPod hipster evangelising mindless repetition of "Firefox is CSS 'compiliant'" type drivel.

  31. Leo Balter

    I can't say thanks for proprietary implementations at all like css filters, activex to make xhr. The same on creeping implementations like document.all. I can't see that as a precursor, the DOM implementations came naturally and I don't see creeping inovations as inspirations. The real inspirations was what users wanted, as it is today.

    Sure we got something good. If you throw a lot of new changes, without regarding if they are good or not, you'll have luck on a few some to come good, and a lot of bad things that made what IE is and what it represents today.

    All major browsers from any time are very important as they helped building the web as we know it today, there're no such special thing to consider IE the only special.

    -- to this article.

  32. Nicholas C. Zakas

    @Leo - I think you need to take context into account. At the time, web browsers were just growing out of their infancy and there was a lot of proprietary development. In fact, Netscape was the one that started adding proprietary features, and Internet Explorer had to follow suit in order to compete. That's just the way the Internet was at that time. While you can be upset about the proprietary nature of the features, it's hard to argue that today's standards features don't owe a debt of gratitude to those proprietary ones.

  33. Nicholas C. Zakas

    @webreac - I think you mean "retelling" of history. :) And Microsoft didn't create CSS, they were just the first to put it into her commercial browser.

  34. Nicholas C. Zakas

    @Webstandard - we don't need filters now, but before we had CSS3, there weren't any other options.

  35. Marco @ Web Mentor

    But but... poking IE is funnnnn!!!!

    I didn't know they were amongst the first to introduce CSS, but I also think the hate they get is deserved. They made the web stagnate with lack of support and thriving the Web forward.

  36. George

    Do not forget protected mode, or sandboxing the webengine. However, was not totally undefeatable, but what cannot be undone?

  37. Steven Wittens

    "All of these capabilities are featured in CSS3 in one way or another. It’s pretty amazing that Internet Explorer 4, released in 1997, had all of these capabilities and we are now just starting to get the same capabilities in other browsers."

    Are you for real?

    Internet Explorer's filters were proprietary, closed-source DirectX filters. Their syntax was terrible, the effects (like shadow) looked ugly, like something out of Windows 95. And they didn't interact well with each other (e.g. PNG alpha + opacity being broken even in IE7). The transitions were clunky and amateur, and invisible to JavaScript.

    If you compare this to the CSS3-incarnations of similar ideas, it's night and day. WebKit published provisional specs, focused on syntax and clarity, exposed events in JavaScript, and did so with production-quality polish.

    Internet Explorer brought some good things to the table, but the DirectX filter/transition "embrace and extend" cluster**** was not one of them.

  38. Dharmindar

    The fun part was activex and allowed access to many system specific resources which was then restricted. I know it was for betterment. But I enjoyed a lots of things with that.

  39. Nicholas C. Zakas

    @Steven - You're kind of missing the point. The point was never about syntax, it was about adding capabilities. The Internet Explorer filters were actually very well documented on MSDN. Keep in mind, this was during a time where standardization was not the norm. Both Netscape and Internet Explorer created proprietary features to compete with one another and neither did much to standardize what they did. Filters were definitely not perfect, but given the capabilities of computers and browsers at the time, it was a pretty magnificent achievement.

    It's easy to say that things are better now, but we live in a very different world than we did over a decade ago. Browser vendors now work within standards bodies where before they did not.

  40. Nicholas C. Zakas

    @Marco - Internet Explorer didn't make the web stagnate. The stagnation came on the part of everybody else who decided not to make web browsers. Netscape completely gave up and no one else stepped up. You can't blame a company for not innovating when they have no competition, there's absolutely no reason to do it, and that's not unique to browsers at all.

  41. Steven Wittens

    @Nicholas: Which is why, aside from syntax, I mentioned the overall shitty quality of the effects, the buggyness and the lack of generality, which made it a dead-end 'spec' that nobody else would touch with a ten foot pole. I wouldn't call filters a magnificent achievement, when they couldn't even get PNG transparency to work reliably.

  42. Nicholas C. Zakas

    @Steven - As I said, you need to take into account what was going on with browsers and technology at the time. All graphics looked worse 15 years ago than they do now. And also, once again, the goal of browser vendors at that time wasn't standardization, so judging them based on whether or not they tried to create an interoperable feature is wrong-headed. Neither Netscape nor Internet Explorer were trying to create interoperable implementations of anything, the fact is that Internet Explorer opened the door to exploring new capabilities so that we could have the major improvements we have today.

    And please, let's keep the colorful language out of the comments.

  43. Robert O'Callahan

    I got involved with Mozilla in 1999. From then until now --- which covers the entire IE6 era, since it came out in 2001 --- I and other Mozilla people have been heavily involved in Web standards and tried to standardize everything we did. The assertion "the goal of browser vendors at that time wasn’t standardization" is simply false.

  44. Nicholas C. Zakas

    @Robert - I know that everyone eventually came around, but I'm talking about the time prior to 1999. Internet Explorer 4 came out in 1997 and there was a lot of proprietary feature war leading up to that point between Netscape and Microsoft. I know by the time IE 5.5 came around, we had the first version of ECMAScript standardized and things were starting to move in the right direction, but your comment hasn't done anything to convince me that the period prior to that was anything other than how I described it. I'd love to hear your stories about the early days regardless. Blog about it sometime?

  45. gman

    You forgot Web Fonts. IE 4 or 5 had support for downloading and use fonts. It took until just like what, 2 years ago, that fonts finally made it HTML5

  46. gman
  47. Tanny O'Haley

    Finally, someone give credit to IE for the things it innovated. Though I still shudder at the rendering issues like the float bug that doubled margins. IE had opacity and gradients (which all the cool kids are doing now) ten years ago. Also I think Microsoft was right about the box model. The w3c standard is why we had to add so much extra markup. Divs within divs so we could use padding.

    I still like Firefox and its more stable rendering engine than IE. And don't get me started on the bugs I've found in Safari.

    Yes the some of the effects were crude, but give them a break, it was ten years ago. I just wish the hadn't turned off clear type when using filters in IE 7.

  48. Tanny O'Haley

    BTW, if filters were so bad, why aren't we up n arms about the special -webkit- effects that other browsers are going to implement with the -webkit- prefix?

  49. MaxArt

    IE6 was a great browser. Back then.

    We all started hating it because it lagged behind innovation. I mean, you can't possibly keep the same browser for more than 5 years!
    We saluted Firefox as a fresh wind blow in the browser scene. It started the new, modern browser war which Chrome is currently winning but it's still open. But now, it's all about standards and security. All the better for the users!

    Meanwhile, IE still have to inherit a heavy burden from the legacy support of IE6. That's why IE7 and IE8 where decent when released, but horrible just some months after.
    IE still suffer from the major problem with IE development: the lack of updates. And this is still caused by older IE versions, which were famous for they feature stability. Many enterprises built their web apps on that and Microsoft couldn't change it.

    Great article, but don't forget that focusin and focusout are supported by Opera and Chrome/Safari too, although Webkits don't allow traditional event registration (which makes feature detection very complicated). Maybe that's because it all started with DOMFocusIn and DOMFocusOut...

  50. Gu Yiling

    Great article! I hope you don't mind that I've translated it into Chinese and posted on my blog. IE's contribution to the web is really honorable.

  51. Nicholas C. Zakas

    @gman - That's a great point, I completely forgot about that.

  52. James M. Greene

    I believe that IE also introduced the TextRange API that led to the standardized Range and Selection APIs.

  53. Dave Massy

    As a former member of the IE team I'd like to thank you heartily for this post. It wasn't all bad :)

  54. Nicholas C. Zakas

    @Dave - my pleasure! I'm glad you enjoyed it.

  55. Abhi

    Thanks for the history lesson.

    Disclaimer: We are Microsoft shop. ASP.NET stack with SQL server. Though, our preferred browser is Firefox and I am a fan of your Javascript books!

    I agree Microsoft and IE introduced a lot of features. It helped advance the technology and innovation. Though, locking itself up did not help anybody. It does not have even have a decent debugger (Firebug and extensions, anybody?). It does stupid things like pop-up a message "Plugins may slow down IE" I don't have any plugins or extensions installed, did not know they existed!

    It is like saying Ford was the innovator in automobiles, so everyone should love Ford. There are people who like Ford, but the statistics show the current performers are the winners in the market. Past innovation is no guarantee of future wins or future loyalty.

    Look at Visual Studio, which I have used since the very early MFC days. By far it is the best IDE for developers (I have used Eclipse extensively).
    .NET is one of the best development platforms. Both of them are fairly open, follow reasonable standards. Though ASP.NET controls suck, because they lock you down.

    Praise is the carrot, now bring out the stick so that Microsoft produces a competitive browser, not another IE!

  56. Nicholas C. Zakas

    @Abhi - the debugger in IE8+ is actually pretty good, have you tried it? A lot of the good stuff from Visual Studio has made it into there.

    The other things you're complaining about are specific to ASP.net, not Internet Explorer.

  57. Skateside

    Douglas Crockford put it best when he said that the biggest mistake Microsoft made with Internet Explorer during the browser wars was declaring victory and leaving the battlefield. It's really refreshing to see someone point out how much IE has improved the web.

    On that point, I'm pretty sure Internet Explorer was able to handle vector shapes (VML) before SVG and certainly long before the <canvas> element

  58. Steven Roussey

    You forgot databinding -- which was huge, and a big reason enterprise apps got stuck on IE after IE5.

    Also forgot VML.

  59. Zoltan Hawryluk

    I was going to mention VML, but @Skateside beat me to it! :-) Same with @gman's comment regarding @font-face -- except I will say that Netscape 4 also supported embedded fonts via the pfr format. Both browsers had conversion tools, however, that really sucked from my experience, so no wonder no one ever used these @font-face back then. :-)

    Great article! Thanks for the walk down memory lane. Out of coincidence (forgive the self-promotion), I just wrote an article that mentions older technology as well and how one awesome web developer, Walter Zorn, used what he had to do work with to make cross-browser 2D graphics in 2002. Hope we don't sound like that old guy down the street that keeps saying things like "Back in my day ... we didn't have no Friendface or Hipstergram! We had Black and White TVs! And we *loved* it!!!!" :-)

  60. Christophe Eblé

    IE also introduced behaviors, I think it was the ancestor of what we call now progressive enhancement, there was also the possibility to customize scrollbars with CSS (that thing came way later in Webkit and is still not supported in the other browsers)

  61. Patrick Samphire

    It's worth remembering, when people talk about Microsoft allowing IE to stagnate, that Microsoft believed that web browsers were not the future. In some ways they were quite wrong (although the growth in native apps does in part reflect their views).

    Those of us who have been using and working on the web since before the first graphical browser remember quite well both the innovation and the frustrations of early browsers, and both Netscape and IE did their share of innovating and frustrating. I personally preferred Netscape, until it went horribly wrong at the end, but IE6 was undoubtedly the best mainstream browser of its time.

    It's crazy to compare modern browser development with those early days. The early days were wild west.

  62. Chris Wilson

    Actually, I implemented quite a bit more CSS in IE3 than that - notably, you had margin support, including negative margins, which made for some really entertaining and useful layout tricks.

    Also, IE4 was the champion of positioning (despite some distinct limitations), which was wildly useful too.

  63. Alexandre Morgaut

    Awesome article

    I highly preferred the namespaced document.all to get direct access to elements with an id than having them directly exposed in the global window object as defined in HTML5 (http://www.whatwg.org/specs.... The only problem is that it mix (as in the HTML5 version) elements retrieved from their name and from their id.

    I tried to have this problem solved via the whatwg mailing list, but it's still there:
    http://lists.w3.org/Archive...

    A good advantage when working maps or property collections instead method calls is that you can more easily expect a smart autocompletion from your tools, and as you've shown it, it is still possible to work with dynamic id value -> document.all[idValue]

    No chance to have document.idElement and document.namedElements magic collections in HTML5?

  64. Shaji Kalidasan

    Thanks for the wonderful article. IE is a great browser but only thing I am nostalgic was about Java Applets. IE is an applet killer. I have been using IE since 1997 and I admire its edit source option, that is where I used to quickly edit the source by just going to view source when I was learning HTML. Netscape at that time and even now didn't have that option. This feature was very much admired by my peers.

  65. Erik Arvidsson

    box-sizing was introduced by Microsoft for IE (5?) for Mac which was the first browser to pass the Acid test.

  66. Pan

    Hi?can we translate this article to Chinese on our website www.ituring.com.cn ?

    Ituring focus on IT and science books and information, and we use markdown on this website. Of course, this article will open to all visitors freely, and there will be a link back if you need.

  67. Spudley

    What this article tells us is something we already knew: That Microsoft are great at producing new features in their software when they have have some competition.

    The great surge of new browser functionalty you've described stopped dead as soon as Netscape gave up the fight.

    Pretty much every 'innovation' introduced by both IE and Netscape during the 'browser wars' was building on the shoulders of the other's work and then trying to extend it in an incompatible way.

    While a lot of it has ended up encoded into the current web standards, many the APIs that we're left with leave a lot to be desired because they were built in a hurry, and deliberately aimed at breaking the competing browsers. Its embarrassing to describe this as innovation.

    It's also embarrassing to see just how abruptly any new development work stopped in IE once they'd won the war. Microsoft lost all credibility over the word 'innovation' with regard to the web at that point.

    And not just the web: MS Word defeated WordPerfect by being the better product after a massive surge in development, which then went remarkably quiet in the years following. And who else thinks that the big Windows 8 UI changes are anything other than a knee-jerk reaction to the sudden competition that MS is experiencing in the operating system market?

    In short, you can trumpet Microsoft's accomplishments as much as you like, but they'll get no respect from me.

  68. Nicholas C. Zakas

    @Pan - feel free

Understanding JavaScript Promises E-book Cover

Demystify JavaScript promises with the e-book that explains not just concepts, but also real-world uses of promises.

Download the Free E-book!

The community edition of Understanding JavaScript Promises is a free download that arrives in minutes.