Responding to Change: Updated Getter/Setter Syntax in IE8 RC 1
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 ECMAScript, the standard that defines JavaScript, was last updated almost 10 years ago. Earlier this year however, a revision that has come to be known as “ECMAScript 3.1” began to make rapid progress toward standardization. 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. 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.
ECMAScript 3.1 includes many extensions to the JavaScript language that make web development easier and more powerful. One of these features is JSON support and we quickly decided that the native JSON API in IE8 needed to be the same as the JSON API that is included in the ECMAScript 3.1 draft. Another feature from the draft that quickly came to my attention was support for getters and setters.
DOM prototypes
For many months we’ve been working on a feature that helps make the DOM more compatible with the JavaScript language by introducing the concept of JavaScript prototypes to the DOM. Using DOM prototypes, savvy web developers can easily extend HTML elements and other DOM objects with new functionality, develop more powerful libraries and abstraction layers, and even replace any built-in properties and methods with their own. This was one of our top-requested programming features by influential JavaScript experts. One very important part of the feature was getter/setter properties in the DOM.
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.
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.
Standards first
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. While our JavaScript engine and DOM won’t have support for all of the ECMAScript 3.1 enhancements in this release, it does mean that web developer code written to add getters and setters to the DOM in Internet Explorer 8 will continue to work now and into the future, since that code will be based on web-standards.
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.
-Travis Leithead
Program Manager
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.
Comments
Anonymous
January 13, 2009
Well, difference between Vista IE8 vs. Windows 7 IE8 kinda amazed me... Will it be same on final or more goodies to come out soon? For instance: http://www.chip.com.tr/konu/Bozuk-CD-ve-DVD-lerinize-bir-sans-daha-verin_10301.html on this URL, IE8 Beta 2 shows as it should be... (Left of the content picture, the index listing) as same as with many standards compliant browsers. Yet, it fails on Windows 7, adding those list object down to bottom of picture. Is it a standart failure?Anonymous
January 13, 2009
Where's the addEventListener methods? Those are the biggest items on the interop list by far.Anonymous
January 13, 2009
You state: "Earlier this year however, a revision that has come to be known as “ECMAScript 3.1” began to make rapid progress toward standardization." This revision was instigated by, promoted by, and is primarily driven by yourselves at Microsoft.Anonymous
January 13, 2009
The comment has been removedAnonymous
January 13, 2009
@ozonecreations - while we'd love to do the array extras, I don't think it's in the cards this release. However, given what Julian just mentioned, there's a strong possibility that we will see these some time in a future release of the browser. Thanks for the other feature suggestions, as I mentioned, public feedback helps drive what we decide to work on during the planning phase. Re: custom events: IE has supported createEventObject and fireEvent for many releases now, though it's not quite interoperable with the W3C's createEvent and dispatchEvent (http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-DocumentEvent)Anonymous
January 13, 2009
The comment has been removedAnonymous
January 13, 2009
As for the question on how we use prototyping, getters,setters and overwriting methods and properties in IE? - Easy. We use it to overcome the buggy or non-existent implementations in IE. With IE8 coming out we hope we won't need to do this but the good news is that we'll be able to fix things ourselves. 1st fix? Asking for the .value of a Select Element? no problem, the getter will now return the true value, as the browser would submit it (known IE bug not returning the innerText value of the selected option element if the value attribute is not set) 2nd fix? When the "click" event on a radio button is fired, we'll check the state of the selected radio button (if it changed) we'll fire the onchange event rather than wait until the user has .blur()'d the field since the value has already changed. 3rd fix? Autocomplete will be set on every form when the native form.submit() method is called. 4th fix? Remaining buggy .innerHTML setters (Table, Select, Object) will be fixed to work properly and not hang the browser. 5th fix? appendChild(textNode) for script and style elements will be fixed. 6th, 7th, 8th,... - we'll have to see what new bugs, old bugs and regressions IE8 ships with. Now we just have to wait another decade for IE7 to be deprecated. ;-)Anonymous
January 13, 2009
Web Using Adobe Flex in Visual Studio What's New in Internet Explorer 8 - Responding to Change: UpdatedAnonymous
January 13, 2009
WebUsingAdobeFlexinVisualStudioWhat'sNewinInternetExplorer8-RespondingtoChan...Anonymous
January 13, 2009
Whoah this is good news! Now we can fix the broken stuff ourselves!Anonymous
January 13, 2009
Excellent news I would like to know more about the plans for IE after the release of IE8. From the response about extra array methods Travis suggests that further improvements will be made. Can we expect Microsoft to start making more regular updates to the browser. Is there any hope that SVG will be included in a future release?Anonymous
January 14, 2009
The comment has been removedAnonymous
January 14, 2009
The comment has been removedAnonymous
January 14, 2009
We need SVG support and Download manager! Eduardo ValenciaAnonymous
January 14, 2009
The comment has been removedAnonymous
January 14, 2009
Let me get this straight... you wouldn't change the UA string in the first beta because you felt it would Break The Web™, but you have no qualms about changing the getter/setter syntax in the release candidate? After all that hemming and hawing about backwards compatibility, you've led quite an effort to get ECMA to standardize on a non-backwards compatible syntax. I also find it odd that you managed to get the "concurrence of all the major browser vendors" on your "more flexible API" when in your Aug. 26 proposal, Microsoft and Google personnel are the only contributors who work for a browser vendor. What level of input did Mozilla or Apple or Opera have to this proposal?Anonymous
January 14, 2009
The comment has been removedAnonymous
January 14, 2009
Honest question since I'm not seeing it in the Working Draft... Where in the new standard is it proposed to be getter and setter? I thought it was supposed to be the syntax defined in section 11.1.5?Anonymous
January 14, 2009
@Edcuardo We don't really need SVG and the current download management is good enough for nearly anybody and the few that have further needs can download a downloadmanagerAnonymous
January 14, 2009
The comment has been removedAnonymous
January 14, 2009
@ozonecreations / MSFT: The Array extensions would be a very wise move since if you don't support them natively we're all going to have to keep our (slow) hacked implementations in IE for another DECADE. The faster we can get this stuff out of our code and into the browser code where it belongs - the better. PS if the generated events are not cancelable, what's the point? either provide full support, or don't bother. (IMHO)Anonymous
January 14, 2009
Well this off topic, but the basics come first. Therefore would someone please explain why IE8 clientHeight returns 4px more than any other browser on the web?? http://gorebayproperties.com/test/clientheight-ie8.html Right now the options are to UA sniff or force every page into compatibilty mode! Not desirable from a browser supposedly supporting the "standards".Anonymous
January 14, 2009
The comment has been removedAnonymous
January 14, 2009
The comment has been removedAnonymous
January 14, 2009
I agree with the other posters that array extras should have been included by default. In your rationale for changing the syntax, you twice cite the usefulness of these additions. Why put the onus on developers?Anonymous
January 14, 2009
I'm fed up with microsoft. Decisions like this one are absurd. In France, Firefox market share is 31%, keep up the good work, and we won't have to care about IE in a couple of years.Anonymous
January 14, 2009
The comment has been removedAnonymous
January 14, 2009
Wow, the getter thing is amazing. You heard it here first, folks: "we gain interoperability by implementing a feature that's in all other major browsers in an incompatible way." /facepalmAnonymous
January 14, 2009
Yeah, I can't believe the IE team hasn't heard all of the complaints! I see it everywhere: "That darn IE team... they keep implementing standards instead of doing proprietary stuff." Oh, wait...Anonymous
January 14, 2009
Good stuff. I initially thought it would be better to implement defineGetter, defineSetter just for backwards compatibility. But I guess until now they have mostly been used to implement:
- IE-proprietary DOM-properties on other browsers, or
- Mozilla / Webkit-specific web-apps. I presume those things will still work, so no great loss. And the ES3.1 approach does seem more flexible and forwards-compatible so all good.
Anonymous
January 14, 2009
The comment has been removedAnonymous
January 14, 2009
The comment has been removedAnonymous
January 14, 2009
@Gérard Talbot: the issue with setting .innerHTML on tables and selects is that it (at least historically) has been MUCH faster to dump in HTML markup rather than build a DOM. If IE8 renders a DOM dump as fast as .createElement(), .appendChild(), setAttribute() called multiple times then thats fine, otherwise the 2 major spots where .innerHTML would be very handy are filling a select, or filling a table. Both of which are horribly broken in IE. :-(Anonymous
January 14, 2009
@Jeff Watkins Unfortunately, defineProperty support for native objects has not been implemented (primarily due to the late timing of the feature change). In the example you provided, our implementation throws a script error on the call to defineProperty so that we future-proof allowing this desired behavior in the future (there's a very low future compatibility risk to switching a script error for working code unless you write code that depends on a script error :-) (please don't do that!) @The Array Extras Sorry, "in the cards" may have sounded like we randomly select features to implement! We clearly see the value in providing array extras--no question about that. Feature design is never done in a vaccuum, and we consider all the other goals of the product release and make trade offs depending on what we think we can build with quality given the resources we have. In truth, this release has focused heavily on the goal of 100% CSS 2.1 conformance (from a web platform angle) and in that area IE8 really shines. Of course, we've done some nice work in other areas of the platform which should not be discounted. Your continued feedback (like what you've already said about the array extras) will helps us prioritise the next big things we should focus on in an upcoming release.Anonymous
January 14, 2009
As long as we can normalize behaviors, welcome to getter: setter: implementation. if(!Object.defineProperty)Object.defineProperty = function(Object, propertyName, getterSetter){ if(getterSetter.getter) Object.defineGetter(propertyName, getterSetter.getter); if(getterSetter.setter) Object.defineSetter(propertyName, getterSetter.setter); }; All this stuff sounds great, hoping the final release will have even more, but I wonder why you chose to do not let all of us to try this RC ( I mean people that do not have Windows 7 yet - I downloaded at home but how can I test in a production environment where bugs or problems are more frequent? ) Thanks in any case and kind regards. P.S. add the canvas tag before the final release, pleaseAnonymous
January 14, 2009
@Travis, about Array Extras: I think the post was about one very simple fact, this particular feature is useful, code is already there for the taking, and since it is a previously-unsupported feature with no conflicts, implementing it would be little more than copy-paste-compile (grossly exaggerated, of course); it certainly is not "done in a vaccuum". (unproductive dig) If, however, IE's source code is so fragile that any code pasting will cause buffer overflows and crashes all over the place, then all right.(/unproductive dig) IE's code base has, however, been cleaned up quite a lot since IE 5 - so I don't think that's the case. I hope, however, that it's not a "not invented here" rejection. It may just not have been considered until now. Nothing prevents you from pulling a Mozilla: it's not planned, but then we work hard at it for a few days, and voila! All ready for late beta / early RCs. Or is there an IE 8.5 planned, for this kind of additions? And don't tell me that can't exist, IE 5.5 fixed a lot of CSS1 bugs present in IE 5.0, while at the same time adding filters.Anonymous
January 16, 2009
The comment has been removedAnonymous
January 16, 2009
@Barry Carlson - #5 sounds like an issue with the 2px beveled edge around the client area. In standards mode we're trying to fix the discrepencies we've had in the past between the CSS layout coordinate origin and various DOM coordinate APIs. For example, it's a "classic" bug that web devs have to account for a 2px difference between event coordinates and CSS coordinates when working with mouse interaction. If you think you've found a bug, please file it on Connect--we want to know about it. -ThanksAnonymous
January 16, 2009
The comment has been removedAnonymous
January 19, 2009
Okay, I am a computer technician by trade looking to enter the web development / design area. I currently use FF 3.0.5 and IE8 beta. I've been having problems with IE crashing every so often and I have all of the event viewer listings but I don't know where to submit them to discuss the issues. I want to see IE8 perform as well as FF so that consumers have a choice of browsers. I don't agree that IE8 is less secure than Firefox, it just uses a different way of securing the browser. I don't like the command bar at all. Give me a choice to return to the standard toolbar, navigation buttons and menu on the left. I do like Firefox interface and the plugin system. I use IE7Pro and that has helped functionality of IE. Keep up the good work of keeping us informed! What I am looking for is a couple of good mentors that can assist me with what I should learn and focus on in the web development area. I know of the Beginning Developer site at MSDN, and I am a member of ACM and IEEE Computer Society which provide over 5400 online courses that include web design and development. Plus both offer 600+ books on Safari and Books 24/7. So I have resources available. If you are interested in communicating with me, please send an email to dinotech at comcast.net I'm checking my email via web right now because i am working on the OPK for Vista and Windows 2003/2008 on my lab computers at home to create a recovery partition. I appreciate any help or advice you can give me. Please visit www.acm.org or www.computer.org for more information on those organizations.Anonymous
January 20, 2009
What about you guys try to pass this test with a 100/100??? Please please please, would make life a lot easier for the mos of us... http://acid3.acidtests.org/Anonymous
January 20, 2009
oooh, forgot another thing: Animated PNG pics support too thank you! ;)Anonymous
January 29, 2009
This is one of my favorite times in the product cycle. IE8 is platform complete and as we get closerAnonymous
March 24, 2009
During Beta1 and Beta2 pre-releases of IE8, we’ve blogged about the performance optimizations done inAnonymous
March 25, 2009
During Beta1 and Beta2 pre-releases of IE8, we’ve blogged about the performance optimizations done inAnonymous
April 09, 2009
In the world of web standards, JavaScript is known as ECMAScript and maintenance of its definition isAnonymous
April 10, 2009
Yesterday was a significant milestone in the web’s continuing evolution—the announcement of ECMAScript,Anonymous
April 16, 2009
프로그램 관리자로서 기능의 사양에 대한 글을 쓰는 것은 (꼭 필요한 사항이기 때문에) 정말 즐거운 일입니다. 어떤 사양에 대해서도 프로그램 관리자는 특정 설계의 장점과 단점의 조화