Hi, I’m Kris Krueger, the Test Lead for the developer platform in Internet Explorer.
When we announced the IE8 Release Candidate, the call to action for site owners, software developers, designers, and administrators was to test with the Release Candidate build and make any changes necessary to create the best possible customer experience with IE8. We stated that we would continue listening to feedback from the community, but would be very selective about the changes to the platform made from there on out. This is an important point – we wanted to be mindful of the work we’d asked you to do. We didn’t want to “pull the carpet out from under you” by changing fundamental ways the IE platform behaved. We did, though, commit to acting on the most critical issues, particularly reports concerning security, backwards compatibility, and completeness with respect to planned standards work. I’d like to communicate the critical platform changes we’ve made in these areas.
For instance, here’s a screenshot of the dialog you get from the router’s firmware update UI after you click the “Start to Upgrade” button:
Clearly, the user can’t easily understand what caused this problem. While we’d obviously prefer that developers fix broken scripts, in some cases this would be really tricky. In the router’s case, for instance, the user would need to update the firmware to get the fix, and it is the firmware upgrade code itself that’s broken!
In light of this, we started looking into compatibility mitigations for this problem. One proposal was that we could prepend a bogus path to the leaf filename so that such scripts will continue to work. We wanted to use a prefix which is descriptive (e.g. so it can be searched for by any confused web developers looking into problems) and which is simple (contains no special characters) because the parsing code we’re trying to help out is likely not very robust.
Upon investigation, we found that Opera 10 alpha is already doing this compatibility mitigation, although their prefix (“C:\fake_path\”) includes an underscore that we’d like to avoid because we don’t want to use special characters and would like to ensure that file path segments are <8 characters.
We elected to prepend “C:\fakepath\” in order to mitigate the compatibility problem. We only provide this compatibility mitigation in the value attribute’s accessor; we do not send the fake path to the server.
During the Beta / RC cycle, we asked for your input via the http://connect.microsoft.com feedback channel. In the released version of IE8, we’ve fixed many of the top platform issues identified using the Release Candidate build. These issues were prioritized based on votes by the community.
If <a> is not followed by a text node, link is extended infinitely
TextArea width:100% on page refresh renders
IE hard assert possiby related to <col></col> giving blank page.
*Very* slow reaction in sites built with JS framework
overflow:auto generates scrollbars even if overflowing element is within overflow:hidden
background image not or not correctly rendered
[RC1 build 18372] [abs. pos.] Image shrinks unexpectedly after hovering a link
IE8 RC1 (Stds Mode) SCRIPT tag causes Major REGRESSION rendering alignment bug
body backgroud-image is not displayed unless body.style.height=’100%’ set explicitly
We also received strong customer feedback asking that we version a set of DOM features we had previously added to IE8’s Quirks and IE7 standards mode.
Below is the list of features that have been hidden from IE7 Standards mode to improve compatibility with IE7.
- The JSON object is now hidden
- [DOM object].toString() enhancements reverted so that only “[object]” is returned, just like IE7
- object.defineProperty/object.getOwnPropertyDescriptor APIs are now hidden
As part of our commitment to standards we have fixed a small number of tests listed on the official W3C CSS 2.1 test suite.
Before you run these tests make sure that you follow the prerequisites listed at the Windows Internet Explorer Testing Center.
After shipping the RC build we listened to feedback on our HTML 5 DOM storage implementation. We acted on this feedback by making two changes to IE8’s DOM storage implementation so that we match the HTML 5 spec. The first change is that we now return null and not undefined for keys that don’t exist in DOM storage. The second change is that we removed the length and remainingSpace properties when iterating DOM storage using a for..in statement. We also removed the binary IDOMStorage and IEnumDOMStorage interfaces from IE8.
Thanks for all the feedback, your feedback has helped us make a better browser!