Internet Explorer is a browser that I have a love/hate relationship with. While I haven’t used it as my default browser since Firefox 1, it still holds a special place in my heart. Despite its faults, it still is an OK browser. But then there are times I wonder what the development team was thinking. For instance, I read Travis Leithead’s, Program Manager for IE8, post on the updated getter/setter syntax in the upcoming release candidate. As he stated in the post, the team first implemented the __defineGetter__() and __defineSetter__() methods, which every modern browser (except for IE) implements:

“Prior to 3.1, ECMAScript did not include the concept of getter/setter properties, but some JavaScript implementations did support them using an API that is mutually supported by several other major browsers and programming environments. When we started working on DOM prototype support, we chose to implement that de facto getter/setter API.”

I personally rejoiced when I tested it in Beta 2 a while back. Not only did I get my beloved getters and setters in IE, but the implementation followed that of what Leithead called the de facto standard. Unfortunately, I kept reading:

“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 now pleased to announce that with the upcoming Release Candidate of Internet Explorer 8, we not only have a high-quality DOM prototypes implementation, but we’ve been able to change the getter/setter implementation to follow the draft ECMAScript 3.1 standard.” (emphasis mine)

Wait... what?! They took out a widely used (ie: every major browser) implementation in favor of a standard implementation that no one, except Microsoft, supports (yet)?!? This coming from the development team that still sees a reason for the all collection to exist, who has yet to implement the standard event model, and trails behind every other browser in CSS support?

Mr. Leithead, why couldn’t you just bolt on the 3.1 implementation while keeping the de facto implementation intact? How is forcing me to emulate the 3.1 implementation in Gecko, Opera, and WebKit interoperability? It’s either that or branch my code (again!!!!). Interoperability? Yeah right.