What Web Developers Have Learned in the Past 10 Years
http://www.htmlgoodies.com/html5/client/internet-explorer-6-what-have-we-learned.html (Back to article)
Now that even Microsoft agrees that it's time for Internet Explorer 6 to ride off into the sunset, what might we learn from the remarkable trajectory of its 10-year run? In 2002, IE6 was the de facto target browser; in 2011, every remaining installation is a pain-point for Web developers and an impediment to further innovation.
Three generations on, Internet Explorer 9 is virtually a complete restart. Like other modern browsers such as Firefox and Chrome, IE9 embraces new technologies such as HTML5 that promise a more exciting, more interactive, and more interoperable web. But IE9 also shows that in many ways it has learned from the experience of IE6. IE9 appears bent on getting right the things that IE6 got wrong, including standards-compliant implementation of new technologies.
A short history of what went wrong with IE6 goes like this. IE6 included technologies like CSS 2 at a time when the spec was still evolving, while there was little consensus on how, or even what, elements of the specification should be implemented (this remained unclear until the introduction of CSS 2.1 in 2002). Then, as XP's default browser, IE6 became entrenched throughout the Web and particularly across the enterprise. With Web users slow to upgrade, IE6 maintained a significant market share over the years, making it impossible for Web developers to overlook or ignore its idiosyncrasies.
No one -- least of all Web developers -- wants to see this history repeated with the next generation of browsers.
It's especially interesting to compare the early days of IE6 with those of the newest modern browsers because the Web appears poised to shift to a new set of common technologies in 2011, much as it did in 2001. In 2001, the shift was from table-based layouts to CSS. Today, we're excited about the potential for creating rich, dynamic Web applications built on HTML5 and CSS3.
With CSS2, IE6 made a bet on a spec that wasn't quite ready. Those implementations got stuck. That doomed developers to compatibility headaches for as long as a significant number of clients left the browser installed. Although most modern browsers are based on standards, browser vendors differ in opinion on when to implement them. The history of IE6 is exhibit “A” in the case against premature implementations.
Auto-Upgrade Is Not a Substitute
Once a browser is in the wild, it can't be pulled back. Browsers (and web technologies) get stuck. They remain in enterprises where admins want to control what software is running. Device manufacturers may also choose not to release updated software. A good example is the Android phone. Google has shipped version 3.0 but the vast majority of users are still on 2.1 and 2.2 and it’s not clear if these users will ever be able to upgrade. As HTML5 expands into more devices (such as TVs, phones, automobiles, and appliances) with longer upgrade cycles, the problem may get worse. Consumer expectations put the burden on developers to support these multiple implementations.
Moving the Web Forward
The browser and the site each have a role to play in the chicken-and-egg advancement of new Web technologies, but if a popular browser starts down the wrong path the impact is felt on sites across the Web. The more widely used a browser is, the more it has to be conservative in its approach to new technologies.
HTML5, promising rich content without plug-ins or extensions, is making progress, but it remains a collection of specs. HTML5 and its related specs cover a lot of ground, providing specifications for technologies ranging from vector graphics to bitmap graphics to audio to in-browser storage. Not all of these sections are at the same level of maturity -- some are stable, while others are almost certain to change as HTML5 proceeds to full W3C recommendation.
With IE9, Microsoft has eschewed the path of implement first, ask questions later. Instead, the company has been selective about the HTML5 technologies it's chosen to incorporate in IE9, taking only those that it believes are tested and stable. These include canvas, SVG, geolocation, and audio and video elements. IE9 also includes new support for a number of CSS3 features.
Browser vendors can also chose to include less stable specs like FileAPI, IndexedDB and WebSockets. It’s enticing because it allows them to rightfully claim that that they are first to implement. But it also puts these implementations into the wild where they risk getting stuck in the enterprise and the growing set of consumer devices in addition to the PC such as phones and slates.
Consumers get stable standards in IE9, but Web developers still need access to Microsoft's early implementations of draft standards. Microsoft makes prototypes available through HTML5 Labs, a site built for testing and vetting of early or unstable web specs. There are two HTML5 prototypes as of this writing, IndexedDB and WebSockets, but the company expects to provide prototypes implementing additional standards through the same site. You can also learn more about this on MSDN.
This clean split between stable implementations (in the browser) and less stable implementations (in prototypes) may work well, but only if new technologies make the leap from prototype to browser soon after they are stable. Waiting too long to implement technology from the prototypes in the browser can also limit the Web’s potential. Only time will tell how that is going to play out.
Learning from IE6
Looking back over the history of IE6 provides some valuable lessons for browser vendors like Google, Mozilla and Microsoft:
• Lesson 1: browsers get stuck (even with auto-upgrade)
• Lesson 2: browsers must adhere to Web standards
• Lesson 3: browsers should balance stable and unstable technologies with consumers in mind
Web developers should choose when to implement new technologies on their sites with these lessons in mind. HTML5 standards have the potential for creating amazing web experiences, but while developers can confidently build against the stable specs they must evaluate and experiment before deploying those that are less stable.
About the Author
Steve Apiki is senior developer at Appropriate Solutions, Inc., a Peterborough, N.H., consulting firm that builds server-based software solutions for a wide variety of platforms using an equally wide variety of tools. Steve has been writing about software and technology for more than 15 years.
This site does business with companies mentioned in this article or associated with the technologies.