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):

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 (48)

  1. SiSL says:

    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: 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?

  2. Mark says:

    Where’s the addEventListener methods?  Those are the biggest items on the interop list by far.

  3. 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.

  4. ozonecreations says:

    Thanks for all the work on updating the JS.  Particularly in regards to the DOM prototypes.

    Disclaimer: I have not been able to do testing in IE8 to date (test machines on a budget….), so some of the things mentioned below may be irrelevant. If so, then ignore me and thanks for all the hard work.

    In regards to the ECMA 3.1 standards support, do you plan on supporting the array extensions such as forEach, every, etc?  These are not only part of the draft but are supported by every other browser available (and added to every framework to make IE compatible).  The utility of these functions is immeasurable and are defacto standards in modern JS programming. Adding these as native array.prototype functions should be quite simple and should definitely be part of the IE8 release code (if it is not already).

    Please put in support for the DOMContentLoaded event that is supported by every other browser vendor.  While it may not be part of any final specification, the utility of this event is beyond compare.  The headaches in trying to simulate this in IE are huge.  As a developer, on things that are this useful and widely accepted as required, I don’t care if it is part of a standard or not, it is a must have.  This is not a situation of something brand new, it has been in the wild for several years now and the behavior behind it is well defined (even if not standardized).  

    In a related note, adding support for custom events (e.g. onFoo), is a desperately needed addition to IE (almost on par with the need for the DOM prototypes).  I know that switching to the W3C event model (add/removeEventListener) is not going to happen this release and I am sure that there are huge complexities with changing event models.  Understandable.  However, allowing for the assignment and creation/dispatching of non-normal events under the current event model should be a high priority.  Given modern ajax style event driven programming, the ability to create custom events is an integral part of the toolset.  Having developed an x-browser event library, I can honestly say that at least 2/3 of the code in that library was for the sole purpose of hacking around this limitation and the DOMContentLoaded limitations in IE.  I expect that every library/framework developer out there will tell you the same thing.  A quick if/else to toggle between attachEvent and addEventListener… not a problem…. writing 100+ additional lines of code to error catch and mimic the entire event model for custom events (including bubbling, cancelation etc) to make IE do what everyone else does by default…. very very painful.

    If you guys are as set on supporting AJAX and related programming as you claim, then please support the needs of modern programming "standards" (in addition to the support for actual standards).  


  5. Travis Leithead [MSFT] says:

    @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 (

  6. William J. Edney says:

    Travis –

    Thank you very much for your post! Your participation here can not be over-estimated and all of us web developers out here *thank you*.

    This is all awesome stuff and most, most welcome.

    2 questions for IE8 (I assume it will be called "JScript 5.8" ๐Ÿ˜‰ )?

    1. Where are you guys at on the Web Workers (i.e. threads) capability being built into FF 3.1 / Webkit nightlies? Some very cool stuff can be done with those, but we really need Microsoft’s participation here.

    2. I know that Dean has mentioned that you guys are ‘not in a horse race with Firefox and Webkit on JavaScript engine speed’, but I think that’s the wrong approach to take. JS engines are becoming faster and faster – the Squirrelfish Extreme engine is *an order of magnitude* faster than IE8beta2 on the Sunspider tests. It’s using virtual machine optimization techniques that have been around for a while, so they’re not exactly new things – they first showed up in the Self language over a decade ago. For those of us building sophisticated JS apps, speed counts. I know you’ve got some amazing language people over at Microsoft, and I can’t help but think they’ve been seeing what’s going on with the other teams. I’d love to see you guys close the gap here, I really would :-).

    Thanks again for your info here.


    – Bill

  7. larry says:

    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. ๐Ÿ˜‰

  8. gOODiDEA.NET says:

    Web Using Adobe Flex in Visual Studio What’s New in Internet Explorer 8 – Responding to Change: Updated

  9. gOODiDEA says:


  10. SchizoDuckie says:

    Whoah this is good news! Now we can fix the broken stuff ourselves!

  11. Mike says:

    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?

  12. satan says:

    gah.. wtf ?

    why can you be interoperable just once ? always reinventing the wheel, although always touting interoperability. Interoperability is only a word in your dictionary, it has no real meaning.

    Object.defineProperty ????

    and then you call the __defineGetter__ legacy and old.

    Why can’t you just support what already exists so the code will out by default in IE? Why does every developer in the world need to run to fix code for each IE release?

    That why developers hate IE. You’re not interoperable with noone nor consistent.

  13. Jeff Watkins says:

    Travis, do you anticipate supporting Object.defineProperty for regular JS objects in IE8?

    For example:

    var someObject= {};

    Object.defineProperty(someObject, "myProperty", {

       setter: function(newValue)


           return (this.__myProperty=newValue);


       getter: function()


           return this.__myProperty;



    Please forgive the formatting, I’m certain it’ll get screwed up.

  14. Eduardo valencia says:

    We need SVG support and Download manager!

    Eduardo Valencia

  15. Anon says:

    @satan:Does "ECMAscript 3.1" mean nothing to you?

  16. Gyrobo says:

    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?

  17. Gyrobo says:

    Wow. I just reread my own post. It sure makes me sound like a jerk.

    But my point remains valid!

  18. -TNO- says:

    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?

  19. hAl says:


    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 downloadmanager

  20. ozonecreations says:

    [quote]@ozonecreations – while we’d love to do the array extras, I don’t think it’s in the cards this release. [/quote]

    @Travis – Adding the array extensions is (or should be) one of the simplest things you can do. I’ll give you the code.  Mozilla posts the code on their website for writing compatibility… They’ll give you the code.  Not including something this simple, yet universally used, is silly.  Look around at the various frameworks out there.  They all have a "if(IE){ fix arrays}" block of code.  If you want to get developer (moral) support, then you can’t drop the ball on the simple/little stuff. This isn’t a case of re-architecting the application.

    [quote]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[/quote]

    You are talking about script generated events (which you don’t support fully since they don’t bubble and aren’t cancelable).  I am talking about true custom events which you have no support for.  

    Try this and see what happens:

    function customEventTest(elemRef){

    elemRef.attachEvent(‘onFoo’,function(){alert(‘I know kung foo’)});



    DOM prototype exposure is great.  The getter/setter stuff is great.  But then we get the querySelector functions that are hamstrung by the selectors they support such that we still have to code our own instead of using it.  You can add that but can’t add the basic array extensions that are in the specification your own team is helping to write?  Come on.  Rate your priorities on actual usefulness.  

    I’m not trying to be rude here, but I keep reading that this release is going to have all of these great updates for developers and ajax support and all of that.  Yet, when you look at the results, we are getting about 1/2 the support needed, which leaves us basically ignoring your additions and continuing to bloat our code to compensate.  That is why we scream so loudly.  It feels like you are creating these tools and have great ideas, but have no experience in real world applications.

    Sorry to be so negative, but frustrations abound.

  21. steve says:

    @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)

  22. Barry Carlson says:

    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??

    Right now the options are to UA sniff or force every page into compatibilty mode!  Not desirable from a browser supposedly supporting the "standards".

  23. I wonder if you would consider including jquery and script manager as part of the browser.

    This would save an initial download of nearly 500KB (uncompressed) or 100KB  (compressed) each time a user visits a web site for the first time.

    Remember these huge files can be stored on each users machine for each web site they visit that uses these technologies.

    I am cetain that I and many others would seriously consider using the script manager if their users did not face this huge download penalty.

    You can also be sure that if Microsoft took the lead on this issue that the other browser developers would follow, think of the early advantage that would be gained by IE.

    This idea was first proposed here:

  24. thacker says:

    All of the discussions regarding ECMAScript, DOM, CSS, whatever, is moot if this RC candidate of IE8 continues with its multiple failures upon attempted launch that I have and continue to experience under Vista.

    God help you, because the market will not, if the final release is anything remotely close to experiences that I see with this release.

  25. Gyrobo says:

    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?

  26. Jean says:

    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.  

  27. Dan says:

    >"Why put the onus on developers?"

    Because there are millions of you and probably only dozens on the IE Team?

    >"Decisions like this one are absurd."

    Following the standards is absurd?  This community cracks me up!!!

    >"Therefore would someone please explain why IE8 clientHeight returns 4px more than any other browser on the web??"

    Because clientHeight refers to the available client area, and IE has a shorter toolbar than whatever other browser you’re testing?

  28. Ryan Cannon says:

    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."


  29. Ted says:

    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…

  30. Sean Hogan says:

    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.

  31. @Larry

    > We use it to overcome the buggy or non-existent implementations in IE.

    Exactly! I’ve said this before and I’ll say it again: if IE Team fixes all the [DOM HTML, DOM Core] bugs, then there would be very little use for defining getters and setters. Again, the top #1 priority in my opinion should be on bug fixing, bug fixes.

    > Asking for the .value of a Select Element?

    Bug filed:

    Voting for that bug (389742) would help everyone involved/concerned about such bug.

    > IE bug not returning the innerText value of the selected option element if the value attribute is not set

    That one has been fixed in beta2:

    > Remaining buggy .innerHTML setters (Table, Select, Object)

    Why not use DOM HTML methods instead/rather of innerHTML for IE 8? They should work as expected.

    @Barry Carlson

    > explain why IE8 clientHeight returns 4px more than any other browser on the web

    1st: there are browsers which support window.innerHeight

    2nd: document.documentElement.clientHeight

    is not exactly the client area; document.documentElement.offsetHeight is not exactly it either but in practice, it can be assumed to be the case.

    3rd: your very own code

    <!–[if lt IE 8]>


    body {margin:0; padding:8px;}



    removes body margin (8px) for IE 7: as far as I can see (your testpage is far from self-explanatory, easy to understand), that is precisely why IE8 clientHeight returns 4px more

    4th: #box {text-align:center;} is illogical since #box has no inline [element] content. ""The [text-align] property describes how text (and inline elements) is aligned within the element." CSS 1, section 5.4.6. Other {text-align:center;} declarations in the code are unneeded, unnecessary.

    5th: setting the document root element’s overflow property dynamically should do/achieve nothing; again, this seems unneeded, unnecessary.

    Regards, Gérard

  32. SVG says:

    "Tim Berners-Lee, the British-born inventor of the World Wide Web"

    "Berners-Lee, director of the standard-setting World Wide Web Consortium, or W3C, said in an interview this week that Internet Explorer is falling behind other browsers in the way it handles an important graphics feature for Web pages."

    "A Web image that is encoded as a scalable vector graphic, or SVG, can be resized to fit the computer screen or zoomed into without becoming blocky and losing sharpness, as happens with images encoded as the more traditional "bitmaps." Maps are one popular use of SVG."

    "If you look around at browsers, you’ll find that most of them support scalable vector graphics," Berners-Lee said. "I’ll let you figure out which one has been slow in supporting SVG."

  33. steve says:

    @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. ๐Ÿ™

  34. Travis Leithead [MSFT] says:

    @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.

  35. As long as we can normalize behaviors, welcome to getter: setter: implementation.

    if(!Object.defineProperty)Object.defineProperty = function(Object, propertyName, getterSetter){


           Object.__defineGetter__(propertyName, getterSetter.getter);


           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, please

  36. Mitch 74 says:

    @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.

  37. Barry Carlson says:

    @ Gérard Talbot

    You effectively rubbished the demonstration page (which had been used originally as a valign testpage), and made an ineffectual argument as to why padding was affecting the outcome of clientHeight. Padding has been set to enable the page to render per W3C browser standards in IE7 and earlier, and is accounted for when the derived clientHeight is applied to the div height.

    1.. The revised page has one div which has its height dynamically set using document.documentElement.clientHeight.

    2.. The switch between IE8/7 is achieved using the recommended meta tags:-

    <meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" /> or

    <meta http-equiv="X-UA-Compatible" content="IE=7;FF=3;OtherUA=4" /> therefore the browser window and client area is exactly the same when switching IE8/7 (in the same tab). The IE8 and IE7 pages are identical except for the above meta tags and the link which includes a CSS hack for the link position in IE7 (another subject).

    3.. Overflow returns the scrollbar in IE8, and as stated earlier the clientHeight in IE8 is 4px greater than the client window height returned by IE7 or physically measured.

    4.. Open the url in FF3 etc. and of course there is no change to the innerHeight/clientHeight when changing between pages. FF3 will respond equally to window.innerHeight or document.documentElement.clientHeight.

    5.. My question still is, "Why does IE8b2 return 4px more clientHeight in the same window than IE7 which returns the correct clientHeight??"

    Regards, Barry

  38. Travis Leithead [MSFT] says:

    @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.


  39. Barry Carlson says:


    I sometimes feel that I’m bashing my head against the proverbial "brick wall", but your comments and advice are appreciated, and I will follow-up as suggested.

    Regards, Barry

  40. 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  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 or for more information on those organizations.

  41. NeXur says:

    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…

  42. NeXur says:

    oooh, forgot another thing:

    Animated PNG pics support too thank you! ๐Ÿ˜‰

  43. IEBlog says:

    This is one of my favorite times in the product cycle. IE8 is platform complete and as we get closer

  44. JScript Blog says:

    During Beta1 and Beta2 pre-releases of IE8, weโ€™ve blogged about the performance optimizations done in

  45. IEBlog says:

    During Beta1 and Beta2 pre-releases of IE8, weโ€™ve blogged about the performance optimizations done in

  46. JScript Blog says:

    In the world of web standards, JavaScript is known as ECMAScript and maintenance of its definition is

  47. IEBlog says:

    Yesterday was a significant milestone in the webโ€™s continuing evolutionโ€”the announcement of ECMAScript,

  48. ํ”„๋กœ๊ทธ๋žจ ๊ด€๋ฆฌ์ž๋กœ์„œ ๊ธฐ๋Šฅ์˜ ์‚ฌ์–‘์— ๋Œ€ํ•œ ๊ธ€์„ ์“ฐ๋Š” ๊ฒƒ์€ (๊ผญ ํ•„์š”ํ•œ ์‚ฌํ•ญ์ด๊ธฐ ๋•Œ๋ฌธ์—) ์ •๋ง ์ฆ๊ฑฐ์šด ์ผ์ž…๋‹ˆ๋‹ค. ์–ด๋–ค ์‚ฌ์–‘์— ๋Œ€ํ•ด์„œ๋„ ํ”„๋กœ๊ทธ๋žจ ๊ด€๋ฆฌ์ž๋Š” ํŠน์ • ์„ค๊ณ„์˜ ์žฅ์ ๊ณผ ๋‹จ์ ์˜ ์กฐํ™”

Skip to main content