IE 8: How to Target a Moving Web Standard

I always wondered how vendors go about making decisions when they're working on a product and the core standards defining the technology behind that product are in flux. Typically, if the standard is important enough to the vendor, it is involved in any standards effort governing the evolution of the standard in question. And it has some say in what the standard will look like.

Such is the case with Microsoft, its Internet Explorer browser, and the ECMAScript standard, which is the standard that defines JavaScript. As JavaScript lies at the heart of any browser, Microsoft has been actively involved in the shaping of the ECMAScript specification.

Indeed, Microsoft helped defeat a proposed ECMAScript 4 specification in 2008, instead pushing for the completion of what will be known as ECMAScript 3.1. However, as the ECMAScript standard has not changed since ECMAScript 3 came out in 1999, it's clear that a change is due. And it is coming soon, while Microsoft is smack-dab in the middle of finishing up work on the latest version of its browser, IE 8.

So, as Travis Leithead, an IE 8 program manager, wrote in a recent blog post:

Despite our best planning efforts, we know that some of the assumptions made in early specs may change at any time through development. One of these common areas of change is in the Web standards space—therefore we plan extra time in our schedule to re-evaluate current conditions and make changes to the product if necessary.

Responding to changes in Web standards during the middle of the product cycle can be challenging for a variety of reasons. Speaking strictly from a development standpoint, feature changes always come at a cost—usually a trail of product bugs which take time to find and fix. Other changes are risky because the standard that they are based on could change. Each time we consider a change, we must carefully weigh the consequences.

Leithead goes on to specifically explain how Microsoft worked to respond to changes in Web standards during the development of IE 8. "Back when we started work on Internet Explorer 8, we expected that any new ECMAScript developments would occur soon enough to give us ample time to integrate them into our planning; we were motivated to revisit that expectation with the recent rapid progress of ECMAScript 3.1," he said. "In particular, we wanted to be careful not to introduce features into Internet Explorer 8 in a way that would be incompatible with what we could see coming in the ECMAScript 3.1 draft."

For instance, ECMAScript 3.1 includes many extensions to the JavaScript language that make Web development easier and more powerful, Leithead said. "One of these features is JSON [JavaScript Object Notation] support and we quickly decided that the native JSON API in IE 8 needed to be the same as the JSON API that is included in the ECMAScript 3.1 draft," Leithead said.