As a Program Manager, I love to write feature specifications (that’s a job description requirement)! In each spec, PMs carefully weigh the pros and cons of certain design tradeoffs, consider the customer requests, available feedback and telemetry data, etc. Based on all of that information, we make certain informed assumptions about what we would like to build and how. 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.
In this post, I’d like to describe a significant recent event in the evolution of one web standard and how we chose to respond to it in Internet Explorer 8. I think this post offers a unique view into the complexity involved in responding to changes in web standards during development, as well as a great forum to announce the change in the upcoming release candidate.
ECMAScript 3.1 made an early decision to include getter/setter properties but by using a more flexible API rather than the de facto API. This decision was made with the concurrence of all the major browser vendors including those who currently support the de facto getter/setter API. With ECMAScript 3.1 in full swing and other browser vendors bought-in, we now had an important decision to make: do we respond to this unexpected change and pursue implementing the ECMAScript 3.1 getter/setter API for the DOM, or do we ship what we have and tackle the ECMAScript 3.1 API in a future release?
The answer really came down to what was best for the web developer; they need interoperability and by ensuring that we support getters/setters as outlined in ECMAScript 3.1, we help deliver that interoperability in the long-term. Given that we were mere weeks away from shipping Beta 2 and did not want to put the quality of that release in jeopardy, we felt it was important to release the existing implementation (de facto getter/setters) to give web developers a chance to test and find any significant bugs rather than cut the feature from Beta 2 (saving it for RC 1). We appreciate the feedback we’ve received thus far, and have been able to take the requisite time to respond to compatibility issues that we might not otherwise have had the time to do.
I’m very excited about this new capability in IE8! To help you get started, I’ve written a few articles that provide an introduction to DOM prototypes and getter/setters (and the new syntax that will be publicly available in the upcoming release candidate build):
- Document Object Model Prototypes, Part 1: Introduction
- Document Object Model Prototypes, Part 2: Accessor (getter/setter) Support
Also, some of you may have noticed that MSDN has also been updated to include the prototypes available in Internet Explorer 8!
DOM prototypes and getters/setters allow for some pretty cool programming possibilities. In an upcoming blog post, I’ll get into more details on some of the scenarios that IE8 makes possible. Please leave a comment and tell us what cool scenarios you’ve already implemented using this feature!
Returning to the topic of responding to change, what may initially appear as the best design for the web may change over the course of a product’s development. The experience I had with DOM getters/setters in Internet Explorer 8 has personally confirmed this. As we finish IE8 and on into the future, we’ll continue to gather the right data, listen to customer feedback, and make product changes where appropriate. I know our team cares a lot about web standards and supporting them as a way to achieve interoperability—which ultimately helps web developers to be more productive; embracing ECMAScript 3.1 is one more step to help get there sooner.
Update 1/15: Please note, in some of the examples referenced in the above links, property descriptors have a “getter” and “setter” property. This was recently simplified to “get” and “set” (for consistency with other parts of the ES3.1 language). This is reflected in our current binaries, and we are in the process of updating this documentation now… sorry for the confusion.