Site Compatibility and IE8

  • [アーティクル]

Reports of broken sites are an important part of the feedback the IE team receives from the community. When we receive a report of a broken site, we take it and identify the core issue causing the problem. A number of these issues end up being side effects of changes we deliberately made in IE8, but even these are useful. They help us identify which IE8 changes have the broadest compatibility impact. In this post I'll share some of these issues with you so you can quickly identify problems affecting your site when migrating from IE7 to IE8.

Differences between IE8 Compatibility View and IE7

We strive to make Compatibility View behave as much like IE7 as possible, but we do make exceptions. Many of these exceptions enable improved security and accessibility features immediately, even for sites that have not yet migrated to IE8 Standards Mode.

Cross Document Communication

Hacks enabling cross-domain, cross-document communication have been disabled for security reasons. SOLUTION: Use Cross Document Messaging (XDM) to work around this change.

Extending the Event Object

IE exposes new properties for certain AJAX features such as Cross Document Messaging (XDM), even in Compatibility View. Adding custom properties to the Event object can conflict with these new properties, such as "source". SOLUTION: Change the names of conflicting custom properties to avoid collision.
event.source = myObject; // Read-only in IE8

event.mySource = myObject;

Attribute Ordering

The ordering of attributes has changed, affecting the attributes collection as well as the values of innerHTML and outerHTML. Pages depending on a specific attribute ordering may break. SOLUTION: Reference attributes by name as opposed to their position within the attributes collection.
attr = elm.attributes[1]; // May differ in IE8

attr = elm.attributes["id"];

Setting Unsupported CSS Values

Assigning CSS values that were unsupported in IE7 but are supported in IE8 Standards Mode will not generate exceptions in IE8 Compatibility View. Some sites use these exceptions to determine if a particular value for a CSS property is supported or not. SOLUTION: Short of version detection, this is a difficult issue to work around. If this behavior is essential to a page, updating the page to run in IE8 Standards Mode may be the best approach.
try {     elm.style.display = "table-cell"; } catch(e) {     // This executes in IE7,     // but not IE8, regardless of mode }

Differences Between IE8 Standards Mode and IE8 Compatibility View

We see the majority of compatibility issues in IE8 Standards Mode. Most of these occur when sites expect legacy behavior that no longer exists in IE8 Standards Mode. Upgrading your site to run in IE8 Standards Mode is the best option in the long run, but in the interim you can quickly fix these types of issues by running your site in Compatibility Mode. This is described in Jefferson's post on the EmulateIE7 meta tag. In addition to the issues mentioned above, here's what you should be aware of.

Version Detection

While other changes are typically the root cause, version detection is where pages often go wrong. This is largely because making the right decision before a browser exists can be next to impossible. Nevertheless, incorrect version detection in conditional comments, script, and on the server side can easily break a page in IE8. This is especially true for conditional comments. They are used by a number of pages to apply fix-up CSS that IE8 no longer needs. SOLUTION: Update pages to make appropriate version decisions. When possible, use object detection instead.
<!--[if IE]>     <link rel="stylesheet" type="text/css" src="ie.css" /> <![endif]-->

<!--[if lte IE 7]>     <link rel="stylesheet" type="text/css" src="ie.css" /> <![endif]-->

Object Detection

Object detection works great when used correctly. However some pages assume the existence of one feature based upon the presence of another, leading to problems when both features are not implemented in the same release. SOLUTION: Perform proper object-detection for each feature used.
if(window.postMessage) {     window.addEventListener(         "load",         myHandler,         false     ); }

if(window.addEventListener) {     window.addEventListener(         "load",         myHandler,         false     ); }

Malformed HTML

Parser error correction for malformed HTML has changed in IE8 Standards Mode. Pages depending on the way IE7 performs error correction may encounter issues as a result. SOLUTION: Ensure your markup is well-formed and valid.
<ul>     <li>1.1         <ul>             <li>1.1.1</li>     </li> <!-- Closes 1.1 in IE8, but not IE7 -->             <li>1.1.2</li>         </ul>     </li> </ul>

<ul>     <li>1.1         <ul>             <li>1.1.1</li>     <!-- </li> -->             <li>1.1.2</li>         </ul>     </li> </ul>

Working with an Element’s Class

In IE7, "className" had to be used as the attribute name to set and retrieve the class of an element. This has been fixed for standards-compliance in IE8 Standards Mode. Using the old approach will create an attribute named "className" that has no affect on the actual class assigned to an element. SOLUTION: Use the standardized name, "class", instead of "className".
return elm.getAttribute("className");

return elm.getAttribute("class");

GetElementById

The method getElementById is now case-sensitive and no longer searches name attributes. SOLUTION: Ensure case-correctness and use getElementsByName when searching name attributes.
<div id="Test"></div> <script type="text/javascript">     // No element is found because of case difference     var test = document.getElementById("test"); </script>

<div id="Test"></div> <script type="text/javascript">     // Element Test is found     var test = document.getElementById("Test") </script>

Generic CSS Prefix Selectors

Generic CSS prefix selectors are no longer supported in IE8 Standards Mode in order to provide standards-compliant CSS parsing. Most often, this affects pages trying to use CSS to attach behaviors to VML elements. This can cause a script error if set dynamically, or a silent failure when hard-coded into the CSS of a page. Ultimately the rule is not applied, leading to effects such as VML not displaying on a page. SOLUTION: Explicitly specify each tag name you want to match when using CSS prefix selectors.
v\:* {     behavior: url(#default#VML); }

v\:polyline, v\:line {     behavior: url(#default#VML); }

CSS Expressions

Support for CSS Expressions has been removed in IE8 Standards Mode. SOLUTION: Refactor to utilize either improved CSS support or DHTML logic.
/* CSS */ #main {     background-color: expression(         (new Date()).getHours()%2 ? "#000" : "#fff"     ); }

/* Script */ var elm = document.getElementById("main"); if((new Date()).getHours()%2) {     elm.style.backgroundColor = "#000"; } else {     elm.style.backgroundColor = "#fff"; }

Native JSON Object

IE8 now has a native JSON object, compliant with the JSON support described in the ES3.1 Proposal Working Draft. Some pages detect the native JSON object, then use it in a non-standard way. This typically results in a script error and breaks handling of AJAX requests. SOLUTION: Define a custom JSON object when using a non-standard syntax or alter the rest of the code to use the standardized syntax.
if(!window.JSON) JSON = myJSON; JSON.encode(obj); // Not part of the standard

JSON = myJSON; JSON.encode(obj);

Initial CSS Property Values

Unset properties on the currentStyle object now return their initial value. Relying on the old initial values for CSS properties such as z-index can cause problems. This is the root cause of issues with the ASP.NET menu control. SOLUTION: Perform a check for both the backwards compatible value and the standardized initial value.
var zIndex = elm.currentStyle.zIndex; if(zIndex == 0) {     // custom code }

var zIndex = elm.currentStyle.zIndex; if(zIndex == 0 || zIndex == "auto") {     // custom code }

Unspecified CSS Property Values

Unset properties on the style object now return the empty string for improved compliance with the DOM Level 2 Style Specification. Expecting CSS properties such as z-index to have a value when they have not been explicitly set can lead to problems. SOLUTION: Perform a check for both the backwards compatible value and the empty string.
var zIndex = elm.style.zIndex; if(zIndex === 0) {     // custom code }

var zIndex = elm.style.zIndex; if(zIndex === 0 || zIndex === "") {     // custom code }

Attributes Collection

The attributes collection no longer contains all possible attributes recognized by IE, but only those that have been explicitly set. Scripts can fail if they depend on natively supported attributes always being present as they were in IE7. SOLUTION: Do not assume an attribute will be in the attributes collection. Check for existence first.
var attr = elm.attributes["checked"]; // Potential script error in IE8 return attr.specified;

var attr = elm.attributes["checked"]; if(attr) return attr.specified; else return false;

That's all I have for now. If you encounter anything else you feel should be on the list, please add it to the comments to help others out.

Tony Ross
Program Manager

Update 3/13/09: Corrected code samples under version detection section.

Comments

  • Anonymous
    March 12, 2009
    Thank you for submitting this cool story - Trackback from progg.ru

  • Anonymous
    March 12, 2009
    Thanks for the tips, Tony. Those will come in really useful. It does remind me though - why doesn't IE8 support addEventListener?

  • Anonymous
    March 12, 2009
    The comment has been removed

  • Anonymous
    March 12, 2009
    In part I have to agree with Jens. Adding another and another way to render a website just makes things even more difficult for developers. This is getting out of hand! I do understand the problem of massive browser rollouts. Most users that surf the web do not know much about the technology (they shouldn't have to, either). Rolling out a new IE8 that does not render the "old" pages because they are not compliant to the new rendering standards of microsoft will of course make users complain and put the blame pureley on microsoft. so microsoft can decide: either they halp the standard users with a half compatible ie7 compatibility mode in the ie8 and pss off developers, or get it done in a technologically straight way and thus pss off the users. the choice has been to go with the users. in a short term view that is understandable, but it is another chance wasted to come clean with a huge part of the web scene and get something out that has a long lasting positive impact on technology, developers and sympathies on the web. considering the migration of many complex applications from the "install" model to the software as a service model I would have expected microsoft to begin paving their way for a long lasting and successful future. many microsoft innovations have been revolutionary, e.g. excel is still a standard nobody can beat. (I like open office, but calc from openoffice just is not as gut. period) but coming to browsers, microsoft has been limping behind Firefox, Opera and even Safari. why? it's the new "window" ;) not to a graphical interface for applications but to the future of technology, communication and knowledge: the internet. guys, you are not evil, you have shown some remarkable work, but this is not one of your best moments. and that is a diplomatic way of putting it!

  • Anonymous
    March 12, 2009
    sorry for the typos. i didn't quite make the switch back to english before writing this post :)

  • Anonymous
    March 12, 2009
    So you’re adding /two/ more mutually incompatible browsers to the mix? Thanks guys! Seriously, this has got to stop. Do you actually think you’re helping people by doing this? Be brave! Accept that sometimes you’re going to have to break compatibility, and that sometimes that might cuase other people to have to do a bit of work.

  • Anonymous
    March 12, 2009
    This is finally going in the good direction. This article should form the basis for a more broadly advertised recommendation. Keep on the good work, and I look forward to IE9, with native SVG and canvas at least :-P

  • Anonymous
    March 13, 2009
    I noticed Microsoft launched its own we have the fastest browser claim. http://www.microsoft.com/windows/internet-explorer/beta/videos.aspx?vindex=14 Where others use mostly javascript benchmarks (preferbly their own) Microsoft show borwser performance test over surfing 25 of the most popular sites. Funny detail in test is that FF is fastest on Microsoft.com, Chrome fastest on MSN and IE8 is fastest on Google.com and Youtube .com

  • Anonymous
    March 13, 2009
    Note : I absolutely have to spread the love on this one. Big thanks to the IE team. . .Keep up the great

  • Anonymous
    March 13, 2009
    In the Version Detection section, I believe you have a typo.  For me, to get IE 7 to pull the correct CSS, I had to use the following syntax: <!--[if lte IE 7]>    <link rel="stylesheet" type="text/css" href="ie.css" /> <[endif]--> Please note, I am using XHTML 1.0.

  • Anonymous
    March 13, 2009
    Problem with this business here is even though you're trying to release IE7 rendering within IE8, you're actually just releasing 2 browsers at once because it's not IE7 and any test's I've run on IE7 sites that look right under IE8 compatibility mode don't look right, and definitely don't look like IE7 renderings. I'm sure there's a lot of that going around.

  • Anonymous
    March 13, 2009
    This is an important list that's going to save developers a lot of aggravation. I would also like to see a CSS-specific list that gives the "top ten" differences in rendering between IE7 Compat and IE8 Standards. In other words, the main differences in how each handles margins, floats, changes in default styles, etc.... Sylvain? Anybody?

  • Anonymous
    March 13, 2009
    This is an important list that's going to save developers a lot of aggravation. I would also like to see a CSS-specific list that gives the "top ten" differences in rendering between IE7 Compat and IE8 Standards. In other words, the main differences in how each handles margins, floats, changes in default styles, etc.... Sylvain? Anybody?

  • Anonymous
    March 13, 2009
    Wow.. I am impressed for the first time.. You guys should really watch the video on this page http://www.microsoft.com/windows/internet-explorer/beta/videos.aspx?vindex=14 So loading a webpage is not about just javascript. It's being viewed in a holistic way. Can't wait for IE8 Final! :)

  • Anonymous
    March 13, 2009
    Robin said: "Accept that sometimes you’re going to have to break compatibility" What part of the central theme of this post ("The IE team broke compatibility in the following ways and you need to take the following actions") failed to register for you? Jens said: "Why give us a "compatibility view" that isn't really compatible?" Because compatibility is never an absolute.  Most sites will work fine in compatibility mode, and some will not.  This post is about how to fix those that don't.   Jens also said: "IE8 will be lightyears behind any competitor" You mean, as the ONLY browser to fully pass the CSS 2.1 standards test suite, IE8 is somehow "behind"?  Hmmm.... WebKit only almost supports CSS 1.0: http://webkit.org/projects/css/index.html Maybe y'all should go over to the WebKit and Firefox blogs and ask them when they'll be as standards-compliant as IE8, eh?

  • Anonymous
    March 13, 2009
    The comment has been removed

  • Anonymous
    March 13, 2009
    The comment has been removed

  • Anonymous
    March 13, 2009
    Nelson> GetElementsByName is THE proper way to search for an element by name, regardless of what browser you're using.   The fact that you suggest otherwise implies that you have no idea what you're talking about.

  • Anonymous
    March 13, 2009
    Thanks, Tony, but we needed this info about six months ago. @Glen: pretty sure Paul's comment included a heavy dose of sarcasm. Nobody who has a clue about web standards really thinks IE has better standards support than Firefox, Opera, or Safari.

  • Anonymous
    March 13, 2009
    Hater, bad assumption. The CSS Working Group (which rates CSS2.1 as a higher priority than any other spec) "have a clue" about standards. Fact: IE8 has full CSS2.1 support and no other browser does. Of course, I'm sure everyone else will catch up, following IE8's lead.  In a year or so, this will probably all be moot.

  • Anonymous
    March 13, 2009
    One of the things that troubles me most about Internet Explorer is that there are so many edge case bugs. It seems like each new feature is tested at the minimum degree possible, and since it is difficult to impossible for an uninvited developer to submit bugs, these edge case issues don't get dealt with before any given version of IE is released. Where Firefox, Opera, Safari, and Chrome generally have no problem with complex interactions of CSS, JavaScript, and HTML, IE often breaks or creates unfathomable results. A simple example is applying opacity to a transparent png, but the list goes on and on so that it seems that almost on a daily basis I discover an Internet Explorer bug I had not yet encountered. I can go months at a time creating complex applications before discovering a bug in the other browsers listed above. I'm trying to understand why this is the case. I think it is partially due to how difficult it is to report bugs, but the png example above has been a known issue for a long time so that cannot be all of it. Maybe because the project is not open source the code doesn't get properly peer reviewed, and because it is not open source the people working on the code do so with a good-enough, job mentality, whereas the developers on Mozilla and Webkit are often working on features because they want to and have a vested personal interest in those features working well. It's not always just a paycheck for them. Maybe again because the project is not open source developers cannot submit patches. Maybe none of those are the answer. I just hope for a future where working with IE doesn't cause me daily frustration and the loss of hours that would have been better spent doing something else. Today I have already spent several hours trying to figure out why IE8 RC1 is hanging/crashing whenever I try to lazy load some JavasScript and CSS onload. After/if I find a workaround for that, then I need to create a workaround for IE8 RC1 not properly applying the style to a tabs menu when dynamically switching themes. Either of these issues alone probably wouldn't be that frustrating. It is just that they add up day after day so that over the course of a year I have lost weeks of work trying to get things to function in IE that just work in the other browsers on the first try. Often I wonder if there are courses at Microsoft that teach MS developers to think in some obscure way that differs from how others think so that where a + b * c gives the intuitive result in the other browsers it returns something unfathomable in IE, and then if IE is kind enough to throw an error, the information given is hopelessly unhelpful. One last example of things doing the unexpected. If you have the Developer Tools pinned at the bottom of a page, and then get an error, and then click "Yes" when prompted, "Do you want to debug this page?", the Developer Tools become unpinned and the pin button no longer works. Please do not unpin the Developer Tools when I click "Yes" to debug.

  • Anonymous
    March 13, 2009
    @Greg Houston: Rather than saying "IE crashes" or "IE doesn't apply a style", why not put up a test case and provide the URL, so we can potentially help troubleshoot or fix the issue? With regard to this: <<Please do not unpin the Developer Tools when I click "Yes" to debug>> Yes, this is unfortunately unexpected but intentional.  Unless the dev toolbar is unpinned in such cases, the breakpointed script in the page interferes with the developer toolbar, leading to the possibility of hangs. thanks!

  • Anonymous
    March 13, 2009
    @bakinnan: Thanks for pointing out the typo. The post has been updated to reflect the correct syntax. @The Hater: I agree having this information sooner would be helpful, but remember this is based upon problems real sites have encountered. Performing the investigations and rolling up the data takes time.

  • Anonymous
    March 13, 2009
    The comment has been removed

  • Anonymous
    March 13, 2009
    I'd like people to differentiate "Full Support" and "Best Support" of CSS 2.1; they are very different. It's true that IE8's CSS 2.1 support is now on par with other modern browsers. But just like them, there ary parts not implemented correctly. Even with this in mind, any serious web developer is grateful for the improvments IE8 brings. It's not perfect, but on a good way. Glad to see it released very soon.

  • Anonymous
    March 13, 2009
    @H, I don't know what other browsers do with className, but getAttribute('class') is the correct and everywhere-supported method to acces that attribute.

  • Anonymous
    March 13, 2009
    Daniel, when IE8 comes out, please point to any test case in the official CSS2.1 test suite that does not pass in IE.  When you fail to do so, you'll understand what "full support" means.

  • Anonymous
    March 13, 2009
    @Rex - Nelson is annoyed about the fact that getElementsByName(name) does NOT return the correct results in IE6, IE7, [[AND WAS NOT FIXED IN IE8!!!] If Microsoft really wants us to use this method for ANY purpose, the least they can do is fix it so that it returns the correct results. I agree with Nelson - the fact that Microsoft hasn't fixed it is a total embarrassment.

  • Anonymous
    March 13, 2009
    @Paul, that's easy, Select elements do not properly support CSS :hover and :focus events. how many more would you like?

  • Anonymous
    March 13, 2009
    Jose: when IE8 comes out, please point to any test case in the official CSS2.1 test suite that does not pass in IE.

  • Anonymous
    March 13, 2009
    <<<does NOT return the correct results in IE6, IE7, [[AND WAS NOT FIXED IN IE8!!!]>>> This method works just fine on my sites in all of these browsers. URL of testcase, please?   (Note, of course, that you're missing Tony's point.  His point is that in IE8 mode, getElementById no longer returns elements based on Name, which was never correct behavior and is finally fixed).

  • Anonymous
    March 13, 2009
    @Tony Ross 1- There are other differences between IE8 Compatibility View and IE7. Try bugs #63 and #117 at my IE7 bugs webpage: www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/NonFloatingElementWrapsAround.html www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/AdjacentSiblingSelectorBug.html There are a few others. 2- From what I understood, currentStyle and runtimeStyle do not provide anything better or additional from using style. Did IE Team consider removing support of these for IE 8? To be able to use getComputedStyle would have been very helpful; even the dev. tools do not return the computed style... 3- Using entirely valid markup code and valid CSS code at all times is the best policy, in the short term and the long term and regardless of rendering modes. regards, Gérard

  • Anonymous
    March 13, 2009
    @Gerard: Thanks for the test cases!  I'm not able to reproduce either of those problems in the latest build.

  • Anonymous
    March 13, 2009
    There are a number of misunderstandings or problems with what some people are saying. 1- The CSS 2.1 Conformance test suite www.w3.org/Style/CSS/Test/CSS2.1/current/ is still under development. Some tests (just a few, not many) do not make sense. The test suite is still incomplete in my opinion. 2- Full support for CSS 2.1 properties and property values is one thing. Impeccable implementation of CSS 2.1 is a very different issue. IE 8 has full support for CSS 2.1 but it does not have a flawless, impeccable implementation of CSS 2.1: there are still bugs to fix, confirmed and validated CSS 2.1 bugs, that is. I fully agree with Daniel's post (#9473608) on this. 3- A reliable DOM support and JS support is equally important when doing DHTML, when writing cross-browser code, when speaking of web standards support, etc. regards, Gérard

  • Anonymous
    March 13, 2009
    @EricLaw From reading your comment, I think you misunderstood me. I'm not saying bugs #63 and #117 have not been fixed. I am saying that #63 and #117 are rendered differently when tried with the real IE 7 and with IE 8 Compatibility View. Gérard

  • Anonymous
    March 13, 2009
    @Paul > please point to any test case in the official CSS2.1 test suite www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t0803-c5504-imrgn-l-05-b-ag.htm www.w3.org/Style/CSS/Test/CSS2.1/current/html4/t1604-c541-word-sp-01-b-a.htm and from my IE 8 bugs webpage: bugs #13, #77, #133, #134, #141, #150, #175, etc. @Jose >Select elements do not properly support CSS :hover and :focus events bug 416378 connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=416378 :focus pseudo-class is supported for select elements. @steve_web > c.) you can't set the border on the select element but that's not true... at least you can set the border on a select element declaratively. regards, Gérard

  • Anonymous
    March 13, 2009
    @Jose -- Interesting that you mention select elements and :focus as an example of IE not fully supporting CSS 2.1. Last time I checked (a few minutes ago actually), CSS 2.1 had the following to say: "CSS 2.1 does not define which properties apply to form controls and frames, or how CSS can be used to style them. User agents may apply CSS properties to these elements. Authors are recommended to treat such support as experimental. A future level of CSS may specify this further." http://www.w3.org/TR/CSS21/conform.html

  • Anonymous
    March 13, 2009
    @EricLaw: These particular issues were not really the point of my post, but here are some test cases as requested. This blog doesn't let me post them all at once. Too many links? Example 1: This is using XMLHttpRequests to load the JavaScript and is injecting the stylesheet into the DOM. In IE8 RC1 everything loads, but the browser spinner keeps spinning and the new page style is not properly rendered. Click on the page once and the spinner will stop spinning. It requires a double-click to get the page to re-render correctly. Either that or go to another tab and come back. http://greghoustondesign.com/examples/internet.explorer/lazyloading/example-01.html Example 2: Here we use post instead of get for the XHR method. Evalutating the JavaScript does not work in IE (including IE6 and 7) as it does in the other browsers. http://greghoustondesign.com/examples/internet.explorer/lazyloading/example-02.html

  • Anonymous
    March 13, 2009
    Example 3: Here we are injecting stylesheets and scripts into the DOM, with one of the scripts injected into the DOM firing off an XMLHttpRequest for another required file. This may work occasionally, but if you hit reload a couple times it will hang the browser so that none of the browser buttons work, and the only thing you can do is end the task in the Windows Task Manager. This issue does not occur in IE6 or 7 or any other browser. This is basically the problem I was having. For scripts on external domains or scripts I wanted cached I was using the DOM approach to script inclusion. For everything else I was using XHR. The two methods however are incompatible in IE8 RC1. Again, this is not the case in IE6 or 7. WARNING: CASUAL READERS SHOULD NOT CLICK THIS: http://greghoustondesign.com/examples/internet.explorer/lazyloading/example-03.html Example 4: This example should not work because I removed a function that is called by one of the included scripts. The problem however is that if you have error pop-ups turned on, a pop-up instance will occur when the missing function is not found, but you will be unable to see the pop-up. This makes it so you cannot read the error or close the error pop-up, and thus the only way to leave the page is to end the task in the task manager.

  • Anonymous
    March 13, 2009
    WARNING: CASUAL READERS SHOULD NOT CLICK THIS: http://greghoustondesign.com/examples/internet.explorer/lazyloading/example-04.html Example 5: This is pretty much the same as Example 1, except the only thing happening is a single stylesheet is injected into the DOM when you click on the "test" link. As before, the spinner keeps going and the page is not correctly styled, but it only requires a single click on the page to get both the spinner to stop and the page to render correctly. Note that in Example 1 it takes a double-click to get the page to render correctly. http://greghoustondesign.com/examples/internet.explorer/lazyloading/example-05.html I still need to make a simplified test case for the issue with the tabs menu.

  • Anonymous
    March 14, 2009
    The comment has been removed

  • Anonymous
    March 14, 2009
    The comment has been removed

  • Anonymous
    March 14, 2009
    The comment has been removed

  • Anonymous
    March 14, 2009
    The comment has been removed

  • Anonymous
    March 14, 2009
    Hi ! Loving IE8 so far but not sure if it's ready for it's release next week at MIX. Please fix the bugs, if you need any more information you can always contact me. (see my website)

Looking at Photo's on Facebook rearly works. I'm talking about the 'next' and 'previous' button to browse trough an album. Sometimes it just keeps showing the loader. Don't have this problem in FF (it is accualy really fast there so must me some javascript problem)

phpMyAdmin doen't really respond very well when I'm klikking 'insert' or 'structure' at the top. There is no compatibility button also. Because of the xhtml doctype of because it is inside a non valid certificate url?

Thanks again ! C Kurt

  • Anonymous
    March 14, 2009
    I have been using Internet Explorer 8 (IE8) almost exclusively since the first Beta became available

  • Anonymous
    March 14, 2009
    The comment has been removed

  • Anonymous
    March 14, 2009
    IE team is now experiencing the pain of what web developers have been dealing with since 2001 and earlier. Will we ever get an apology from Microsoft? I would expect: "Dear developers, as Balmer's monkey dance showed, we believe developers are important.  We are now experiencing the same issues we have imposed on you for the past 8 years, and now understand why you all hate us.  We're sorry, and although we know we have lied to you about this in the past, but this time we're serious.  We're going to dump IE, switch to WebKit, and add ActiveX capability to WebKit.  All changes will of course be submitted back to the windows branch of WebKit under the same licensing.  The pain of web development is finally over, and although we won, all we did was cause businesses to spend billions of additional dollars in cross-compatibility coding and testing, and additional rework for IE7 and 8 releases." Of course it doesn't have to be webkit.

  • Anonymous
    March 14, 2009
    It's nice to see these updates. I hope this is the beginning of a change in attitude to valuing standards over backward compatibility. Following web standards means compatibility with other browsers. And wouldn't you rather have current compatibility than backward compatibility? Also, if you get ahead on the standards other people will have to catch up with you. Wouldn't that be a nice change?

  • Anonymous
    March 14, 2009
    MS would be quicker dumping the current IE8, put a webkit version together and releasing it. Done! I've now started adding messages to IE6 users in my websites to upgrade (www.bikingdirect.com) - Will I being doing the same for IE8?

  • Anonymous
    March 14, 2009
    Whatever MS is doing with IE8 (and anything else actually) ,they going to be flamed to death by clueless brainwashed idiots . Anyway, i dont like that IE is removing support of things like css expressions instead of working those usefull features into the so called standart. Its a shame to see MS going after this idea of "complying to standarts" by removing usefull features and knowingly breaking 1000s of sites.

  • Anonymous
    March 14, 2009
    Daniel, attribute 'class' is not supported by JavaScript in Firefox or Safari, both return an error. Here is what W3 DOM specs says about it in http://www.w3.org/TR/2000/WD-DOM-Level-2-HTML-20001113/html.html: className of type DOMString: The class attribute of the element. This attribute has been renamed due to conflicts with the "class" keyword exposed by many languages. Let's hope MS will change 'class' back to 'className'

  • Anonymous
    March 14, 2009
    @Conker: CSS Expressions are useful, but come at a very significant performance and reliability cost.  Prior to IE8, expressions were primarily used to implement CSS features that IE did not support.  Now that IE8 has full CSS2.1 support, we can remove expressions and gain the performance and reliability benefits. @Ian: A browser is made up of a lot more than just a rendering engine, and none of the popular engines (Gecko, WebKit, Trident) can be simply "dropped in" to replace another. @Matt asked "wouldn't you rather have current compatibility than backward compatibility?" We need both.  If we didn't offer backward compatibility, most users would never upgrade to IE8, making all of the standards-improvement work we've done entirely moot. @Greg: Thanks for the test cases! Example 1: I see identical behavior between the current IE8 build, FF3, and Chrome. Example 2: I'm not sure exactly what you're saying happens?  If I run this with a clear cache, the example runs fine.  If I run it after running example 1, your server does not return a script for required.js and required2.js, instead returning a HTTP/412 error.   Example 3: I am not able to reproduce any hangs with this page in the current IE8 build. Example 4: I am not able to reproduce the problem with the "Error details" popup in the current IE8 build. Example 5: I am not able to reproduce the problem with the current IE8 build. @CKurt: The Facebook gallery issue was a fascinating bug, which could be seen even more clearly when trying to customize products on TinyPrints.com.  The problem was a side-effect of Javascript garbage collection improvements.   Facebook (and many other sites) use Javascript functions that create new Image() objects with function scope.  The creating function scope never added those objects to the DOM or saved them in a globally-scoped variable.  Instead, the creating function attached onload() handlers to those Images, and those handlers are expected to fire when the image download completes.   Unfortunately, the garbage collector, after exiting the function, would notice that the Image objects were now out of scope and did not exist in the HTML DOM, and would dutifully collect these Image objects, so the onload function would never fire.   This issue was resolved in a post-RC1 fix. I haven't heard of the "phpMyAdmin" bug; can you provide some steps and a url to reproduce?

  • Anonymous
    March 14, 2009
    The comment has been removed

  • Anonymous
    March 14, 2009
    @Stan Regarding getElementsByName(string), bug 412951 has been filed and has been postponed: Bug 412951: IE8 RC1 (Stds Mode) document.getElementsByName(name) returns incorrect results connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=412951 So, there is very little to do for now regarding this bug. What I don't understand is why web authors would choose to set the same name to several elements and also to the id of an element. The workaround for such webpage is very easy to do, to find, to figure out. regards, Gérard

  • Anonymous
    March 14, 2009
    I will say IE 8 is lighter and faster than its predecessor. But this doesn't make my life happy as a developer, which means new condition checks for IE 8 now! This is going to add a new set of woes that I face making my site compatible for IE 6 and IE 7 versus other browsers.

  • Anonymous
    March 14, 2009
    you know those little favicons that you guys invented - the really easy way of identifying any site that you are viewing? Well in IE8 RC1 for reasons unknown they are completely missing from the address bar drop down making it nearly impossible to make a quick visual "ah ha!" when looking for the site you want. In statistical terms, this is like a 400% downgrade in usability.  Please clarify for all the readers here that this has been fixed in internal builds and will be part of IE8 RTM when it ships. thanks

  • Anonymous
    March 14, 2009
    What is it did MS change in IE8 so that http://www.gwt-ext.com/demo/ JavaScript works even slower than on IE7? Thanks

  • Anonymous
    March 14, 2009
    Eric Law, I don't know which version of Firefox you were using to test Greg Houston's IE8 bug issue #1, but Firefox 3.0.7 renders the page accurately with no issues.  

  • Anonymous
    March 14, 2009
    I love how this is written like microsuck is the standard and not the w3c

  • Anonymous
    March 14, 2009
    @EricLaw, if you claim improved results for a yet undisclosed IE build it might be prefereable if you put up some screenprint results.

  • Anonymous
    March 15, 2009
    מעולה. סוף־סוף מיקרוסופט דוחפים את אינטרנט אקספלורר לכיוון הנכון. מעניין כמה אנשים יצליחו לקרוא את התגובה הזו. :)

  • Anonymous
    March 15, 2009
    The comment has been removed

  • Anonymous
    March 15, 2009
    We used to simply call this "vendor lock-in".   Now many seem to believe Microsoft is simply trying to make the internet "better".   Patently untrue.   What they are doing is attempting to make the new OS - the browser - as proprietary and exclusionary as their old OS.  Understandable business need, unfortunately IE is built on a foundation of Sand (Windows).   My recommendation - buck the crowd and build for a common denominator of functions that work across browsers and OS's and refuse the "helpful" enhancements available exclusively from Microsoft.

  • Anonymous
    March 15, 2009
    > Maybe y'all should go over to > the WebKit and Firefox blogs > and ask them when they'll be as > standards-compliant as IE8, eh? That would probably be premature at this point, since IE8 has technically not actually been released yet, last I checked.   Hopefully it will be soon...  the sooner the better, as far as I'm concerned.  IE7 is starting to feel painfully dated.  Not as bad as IE6 got to be, but we don't EVER want to see an IE release cycle that long again.

  • Anonymous
    March 15, 2009
    @MSFT     Why don't you release intermediate versions like ie 8.1, 8.2, 8.3 at few months interval.... this makes easy for you to develop the browser sooner... FF and other browser follow these things and so they are able to cook the browser soon and make them bugles. If you find any bug in ie8 don’t post pond it to ie9 (people can not wait for 2-3 years) but just fix it by releasing smaller version...

  • Anonymous
    March 15, 2009
    @MSFT     Why don't you release intermediate versions like ie 8.1, 8.2, 8.3 at few months interval.... this makes easy for you to develop the browser sooner... FF and other browser follow these things and so they are able to cook the browser soon and make them bugles. If you find any bug in ie8 don’t post pond it to ie9 (people can not wait for 2-3 years) but just fix it by releasing smaller version...

  • Anonymous
    March 15, 2009
    @Don Nelson: Yes, Chrome, Firefox, and IE8's current build all give the same results, which I believe to be correct. @hAl: Either you trust me or you don't.  If you think I'm not trustworthy, then why would you trust me not to photoshop the results?  Of course, what possible reason would I have to try to mislead you in the first place? @major: The Favicons have never been shown in IE8's dropdown.  The enhanced search filtering feature should be useful for quickly filtering the results.  

  • Anonymous
    March 15, 2009
    I thought what "ie8 fan" say about releasing smaller version of IE after the major version would be a great idea. Like ie 8.1, 8.2 or even 8.01, 8.02. Rather than allowing us to wait for 2-3 years for new version. Microsoft did it before. Why can't it do it again?

  • Anonymous
    March 15, 2009
    The comment has been removed

  • Anonymous
    March 15, 2009
    You also made .value for a <input type=file> return just the file name rather than the full path, didn't you?

  • Anonymous
    March 15, 2009
    @Jonas: Yes, that's what you'll see in RC1, and is one of the security measures to which Tony alluded.  For the final release, the .value accessor will return "C:fakepath" before the filename.   That is a compatibility measure that keeps most verification Javascript working correctly.  I expect to do a separate blog post on this topic sometime in the near future.  Thanks!

  • Anonymous
    March 15, 2009
    So um, I'm going to have to make my code with 3 new IE's with the release of IE8, not just one? IE8, IE8 in compatibility mode, and IE8 running as IE7... yay... I look forward to the day when I can open it in Firefox, Opera, Safari... and even IE and have it look the same, IE's the only one that's missing on that list...

  • Anonymous
    March 15, 2009
    Freman- You seem confused.  "IE8 running as IE7" /is/ "IE8 in compatibility mode". In my experience, "IE8 in Standards mode" generally looks the same as the latest version of Firefox, Opera, Safari and Chrome.  All of these have some quirks, but they're mostly compatible. If you want to force your page to render in IE8 standards mode (and BLOCK users from putting it into IE7 compatibility mode) you can use the X-UA-Compatible: EmulateIE8 header.

  • Anonymous
    March 15, 2009
    DISAPPEARING TEXT, RC1 edition (6001.18372) Here: http://www.amberchess2009.com/RoundReport1.html (click on the incomplete paragraphs to make the missing text appear) You may or may not have to ctrl-refresh a few times to reproduce the problem. Reproduces very reliably here, though.

  • Anonymous
    March 15, 2009
    When will IE8 RC2 be released? I'm tired of the bugs in RC1 already and want to test a version of IE that is much, much, much closer to the final RTM version than the RC1 garbage. I'm still seeing lots of rendering issues that should have been solved by now.

  • Anonymous
    March 16, 2009
    @Rex, "Nelson> GetElementsByName is THE proper way to search for an element by name, regardless of what browser you're using.   The fact that you suggest otherwise implies that you have no idea what you're talking about." Actually you completely missed what Nelson's post was saying, and the fact that you replied like this implies that you have no idea what you're talking about AND you have no idea what Nelson is talking about. This IS what Nelson said : "Fix it in IE8 properly and then (and only then) talk about this method.  If you can't implement this ridiculously simple method properly, you might as well drop it from the DOM methods you support." CLEARLY he's talking about IE8's bugged/problematic implementation of the getElementsByName method, and he suggests that MS should not tell us to use getElementsByName to fix ANYTHING in IE when IE's implementation of the getElementsByName is bugged, which is quite logically sound. So try to actually read what others are saying before you attempt to reply.

  • Anonymous
    March 16, 2009
    @Glastheim: Tony's suggestion that developers not use GetElementById to search for elements by name is an entirely reasonable one.  As Gérard notes, the problem with that function is an obscure case and is trivial to workaround. @Dennis: As previously requested, we welcome test cases that demonstrate problems you've found in the RC1 build. @tinokun: Several issues around "missing text" have been resolved, and I'm unable to reproduce the problem you've described in the current build.  Thanks for the test case!

  • Anonymous
    March 16, 2009
    Regarding support for two versions: You do not have to support two versions.Simply use compatibility metatag to use latest or IE8 engine and problem is solved.(You have at worst TWO versions to support,since it overrides user-side selection.) Folks,please think a bit,this was covered on this blog several times! link: http://blogs.msdn.com/ie/archive/2009/02/16/just-the-facts-recap-of-compatibility-view.aspx @Mike Chorns:No lockin.Ýou have it exactly backwards. @about webkit,I suspect it is not technically ,from license standpoint and from compatibility possible.

  • Anonymous
    March 16, 2009
    @Gerard Talbot "2- From what I understood, currentStyle and runtimeStyle do not provide anything better or additional from using style. Did IE Team consider removing support of these for IE 8?" Not quite sure how that's relevant here but you are wrong about this. Both are quite useful. Runtimestyle allows you to "override" any CSS rules - either those set inline with "style" or set in a style sheet. Runtimestyle acts as if it has a greater level of specificity. This is quite useful in many situations. It is very similar in effect to the getOverrideStyle method contained in the W3C DOM Level 2 spec. http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-OverrideAndComputed Which says: "The getOverrideStyle method provides a mechanism through which a DOM author could effect immediate change to the style of an element without modifying the explicitly linked style sheets of a document or the inline style of elements in the style sheets. This style sheet comes after the author style sheet in the cascade algorithm and is called override style sheet. The override style sheet takes precedence over author style sheets. An "!important" declaration still takes precedence over a normal declaration. Override, author, and user style sheets all may contain "!important" declarations. User "!important" rules take precedence over both override and author "!important" rules, and override "!important" rules take precedence over author "!important" rules."

  • Anonymous
    March 16, 2009
    In regards to concerns about supporting multiple modes for IE8: As a few people have pointed out, the web developer has ultimate control over which mode their page is viewed in through the use of the X-UA-Compatible meta tag. KEY TAKEAWAY: Whichever mode you specify is the only mode you need to test against in IE8. The choice for most people comes down to two options: For the most backwards-compatible experience: <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE7" /> For the most standards-compliant experience: <meta http-equiv="X-UA-Compatible" content="IE=8" />

  • Anonymous
    March 16, 2009
    Great information and direction for a standard! I have been using IE8 almost exclusively since the first Beta became available.

  • Anonymous
    March 16, 2009
    @Tony Ross: I don't agree. Case in point: IE 6 was released with Windows XP. Windows XP will be supported until 2014. IE 7 came out with Vista. Vista will be supported until 2017. Meaning that there will be IE 6 and IE 7 users until these dates. Meaning that there will be a need to test a website against IE 6,7 and 8 until then. Now, what do developers think? Simply put, do the most with less time; if IE 7 and IE 8 (compat.) have the same rendering engine, then testing in one will work in another. However, as this article points out, it's not the case. And IE 6 needs workarounds anyway, so it's a given; but still. At the same time, there are not many website designers that don't work with Firefox/Opera/Safari/Chrome/etc. meaning that they would have enjoyed working with an IE 8 that worked in that playground, but things are even worse here: although IE 8's CSS 2.1 is exemplary, the rest doesn't follow (still no DOM2 event management). Meaning that IE 8 is an alien: it doesn't fit with "buggy" IE6/7, but it's also "not-quite-standards-compliant" - meaning it's yet another different platform to test a website against. Now, it's true that, say, Firefox, Safari and Opera (to cite but three that have widely different engines) are not 100% compatible one with the other:

  • Firefox has an old rendering engine that still has several legacy behaviors that could be found surprising (scrollbars in overflowing boxes for example);
  • Safari has very little XHTML support;
  • Opera makes a mess of keyboard events when used with addEventListener. Still, in most cases, creating a website tested against Firefox (which has the best developer tools out there) will work with at worst a few pixels being off in Safari, and with some careful footwork when using the keyboard, in Opera. However, testing the same against IE 8 will go boom for too many reasons:
  • events will be ignored altogether, for IE 8 has no addEventListener support
  • ECMAscript may be disabled altogether or the page not show on the very first DOM modification, if done before the DOM is loaded (and, although it's not standard, I, at the very least, would have very much appreciated DOMContentLoaded support)
  • vector graphics. Remember that VML was both rejected by ISO and deprecated by MS (dixit OOXML spec) Meaning that IE 8 is another completely different browser to test and "validate" a website against: its "standards quirks" mode isn't like its predecessor's, and its "standards edge" mode isn't coming close to matching other browsers'. Now, one way to "solve" this would be to include IE (latest version) as the only browser in future service packs for supported OSes (XP, Vista) and EOL'ing IE 6 and 7 (standard 18-months support for previous SP policies apply, etc.) - which would promptly remove that legacy baggage. Worst thing is, the reason it isn't done is because "major clients want a stable platform"; I guess those clients won't install 7, then. Moreover, if that really was the case, XP SP1 would still be supported (considering the deep architecture changes in SP2, XP SP2 was altogether a new OS) and Vista would still be sloth-slow in disk-to-disk copies.

  • Anonymous
    March 17, 2009
    <blockquote>Meaning that there will be a need to test a website against IE 6,7 and 8 until then</blockquote> The need for testing webasites for older versiosn of IE derives not from the existance of support for older software but for the amount of usage of those browsers. Effectively for informational sites there is no need for support for a browserversion when a browser browser falls below 10% and is declining. For a commercial site the threshold might be 5% (and declining). For a government and banks this might be even a bit lower. IE6 is likely to fall below 10% next year and lower than 5% the year beyond. With IE8 an important update for all IE7 users it migth decline in similar fashion or mayby one later behind. It is therefore very likely that IE6 and IE7 will fall well below 5% market share in 2012 and that IE6 support on many sites will already disappear in the upcoming year

  • Anonymous
    March 17, 2009
    i hope all IE's togather will reach 5% and below.

  • Anonymous
    March 17, 2009
    @hAl: if IE 6 was EOL right now, and IE 7 put forth as "security update" to IE 6: how many IE 6 installs would remain? If the same happened on IE 8's RTM with an 18-month delay before end of support for IE 7, how much market share would IE 6 and 7 retain at the end of the 18 months? How many users currently use IE 6 (and 7) right now because they WANT TO compared with:

  • they don't know any better and disabled automatic updates because, well, it's annoying,
  • it's corporate policy, and since IE 6 still has security updates and support... Heck, I betcha we wouldn't see more IE 6 than 5.0 right now if XP SP3 bundled IE 7 - which had been out for a year before then, and thus had entitled SP2's IE 6 support a further 18 months! I'll tell you: as much as there are Windows 2000 machines still running. And 2k will be EOL in 2010. I'd gladly stop supporting them in my websites (it's a conditional comment away, and I have my fingers on the DEL key) like I stopped supporting Firefox 1.0 or Opera 8 the day their editors stopped supporting them! What I don't understand is that, by keeping support for those "big" corporations that require IE 6, Microsoft is preventing sales of Vista (since it comes with IE 7) and will hamper future 7 sales (since 7 will come with IE 8) because MS STILL supports IE 5, 6 and 7.
  • Anonymous
    March 17, 2009
    @Eric Law [MSFT] - (re: getElementsByName) "As Gérard notes, the problem with that function is an obscure case and is trivial to workaround." I disagree - 100%. For starters, using the method on a production site/application without a fix is dangerous. Therefore there are 2 choices: Don't use the method at all, ignore it completely even though it is quite helpful.
  • or - Do make use of it and handle IE's broken implementation in versions (6,7,8,?) because no other browser has issues with it. However it isn't that simple. document.getElementsByName(name) returns a live NodeList. 1.) Currently there is no way to build your own NodeList or modify one returned from any DOM Method. So for starters, we're going to have to resort to a Static Array in IE instead of a Live NodeList. 2.) We need to override the existing implementation with our own implementation. 3.) The revised implementation needs to re-iterate over the results returned from the native .getElementsByName(name) method to filter out any elements that (a) do not have a name attribute, (b) have a name attribute, but with a value that is not a CASE-Sensitive match of our requested parameter, & (c) (as a result) any elements that have an id attribute that matches incorrectly.

Now we (developers) need to load and add this logic to each and every page where we might call this method to ensure the correct results are returned. Or we simply get Microsoft to do what they did with document.getElementById(id), and in IE8 Standards Mode fix the method to only return the correct results. Now I don't do much coding in C/C++ but this sounds like [[[ a 30 SECOND FIX !!! ]]] Let me repeat that: [[[ a 30 SECOND FIX !!! ]]] Once more, [[[ a 30 SECOND FIX !!! ]]] Please tell me why on earth this is not being fixed in IE8 RTM/RTW? Please state the business case behind not taking a measly 30 seconds of a developers time to fix a most obviously broken DOM Method implementation when you've already taken the plunge with IE8 to go down the standards road and start fixing IE. @Dean, @Chris, @Justin, @Tony S., @Bruce, @Tony R., @Sylvain, @Travis, @Sunava, @Adrian, @Allison, @Marc, @Scott Anyone care to step up to the plate and explain this one to the crowd reading the IE Blog? Better yet, anyone care to step up to the mic at Mix09 and declare why this implementation disaster is still in IE8 RC1? Seriously, Tim

  • Anonymous
    March 17, 2009
    Tim, I suspect you'll see that your obnoxious behavior won't get you anything you're asking for.  Most of us learned such lessons at 4 years old. The idea that this bug is somehow "dangerous" is simply absurd.  You're in control of the content you generate.  Most sites have no need of this method at all, and if they do, it's trivial to simply not ID elements with a token used as a NAME that you plan to seek with this function elsewhere. Your assumption that /any/ bug requires only "a 30 second fix" suggests that you know very little about professional software development.

  • Anonymous
    March 17, 2009
    As a suggestion, you could make a mention within your post that even though the getAttribute behaviour regarding class vs className has changed, the property has not changed and can still be accessed using document.getElementById().className .

  • Anonymous
    March 17, 2009
    I expect that many websites will not work properly on IE8. It's important to check compatibility before it released officially.

  • Anonymous
    March 17, 2009
    @Tim W "no other browser has issues with it." Opera 9.64 and Opera 10.0 alpha 1 build 1345 fails Stan's test (added in bug 412951) @Nelson, Jose, Stan, glastheim, Tim W and others If you visit MSDN's getElementsByName, msdn.microsoft.com/en-us/library/ms536438(VS.85).aspx they do clearly state that id-ed elements will be returned in the nodeList. I think they should also state they are not compliant with DOM 2 HTML though. Before using any DOM 2 method, a responsible web author should read the spec and then establish + understand when and how to use such method. Finally, you should all visit bug 412951 connect.microsoft.com/IE/feedback/ViewFeedback.aspx?FeedbackID=412951 and then validate + vote for that bug. In 3-6 months from now, no one will remember your posts but having several validations and votes where it counts can make a difference. Anyway, that bug has been postponed: it's not that IE Team does not want to fix such bug... regards, Gérard

  • Anonymous
    March 18, 2009
    The comment has been removed

  • Anonymous
    March 18, 2009
    @Tim W, Gerard Talbot, Dan etc. I realize that Tim is quite frustrated with the lack of progress and visibility into fixing IEs getElementByName method. On the one hand ranting on this blog doesn't work but it happens often because the IE Team doesn't seem open to listening to users and developers complain. Anyone want to bet that IE Feedback on Connect will not shutdown the second IE8 goes RTM? I certainly believe that it will be trashed once again when IE8 ships and once again the IE Team will blissfully ignore the bugs that were entered and not fixed. Now as for the method in question - 30 seconds might be a bit tight but Tim is right.  The fix for this shouldn't take even the most junior of developers any time to correct and checkin. So the question does beg an answer, and the IE Team should step forward with one to explain why they felt that fixing this gross mis-implementation of the ECMAScript document.getElementsByName specification. http://www.w3.org/TR/REC-DOM-Level-1/ecma-script-language-binding.html Based on the date of the spec, waiting 10 years for a fix - and then not getting it - is a big slap in the face to developers that have stood by and waited for IE to catch up and start supporting standards. Tim talks about the Business Case, and lets face it, this is what it all boils down to for proprietary software - What is the business case for Microsoft to spend 60 seconds to 5 minutes to fix this bug. Well lets break that one down shall we? If it gets fixed: 1.) 10,000+/- developers will be happier, and now able to use this method 2.) Outside of addEventListener all major ECMAScript DOM methods will actually be half decently supported in IE If it does NOT get fixed: 1.) 10,000+/- developers will remain ticked off at Microsoft for not putting forth enough effort to ship a complete product 2.) developers will STILL not be able to use this method because it is broken 3.) Microsoft loses a lot of face.  This is probably the biggest issue. 5min of work, verses the next decade of bad publicity, blog rants, bug reports, frustrated developers, and general distrust and disdain towards Microsoft as the 800lb gorilla in the room that continues to Break The Web [TM], for no "apparent" good reason - other than to shaft the competition by trying to make a broken proprietary behavior become the defacto standard by abusing market share. +1 for a public statement on why this isn't being fixed. +1 for the MSDN docs being updated to include ALL W3C/ECMAScript specification infractions. +1 for ANY increased level of open transparency to IE development. aaron

  • Anonymous
    March 18, 2009
    I'm still wondering why they're breaking className in the name of standards support.  The reason className is used universally is that class cannot be used, as in ECMA it's a reserved word.  There's a reason every gen three and later browser uses that property name, and switching to something new is just breaking all the existing code out there. The standard says the property name "class" is illegal, in the same way that naming a property name + would be. The requisite page of the ECMA 262 standard is page fourteen (section 7.5.3). http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf There is no change to the reserved keywords lists in other later standards, such as the 2005 ECMA 357 which IE does not implement. So what's this about standards compliance?  Which standard are you guys reading?  Mind pointing out a page that requires you to make this impossible and extremely ill advised change?

  • Anonymous
    March 18, 2009
    Aaron, your assumption that /any/ bug requires only "a 30 second to 5 minute fix" suggests that you know very little about professional software development.

  • Anonymous
    March 18, 2009
    John Haugeland, you're confused. If you use Javascript to set/query the property directly, you use element.className.   If you use the GetAttribute method to query the property, you pass the HTML name of the attribute, which is "class".   http://msdn.microsoft.com/en-us/library/ms536429.aspx http://msdn.microsoft.com/en-us/library/ms533560%28VS.85%29.aspx This isn't the only instance in the DOM where a document attribute is accessed using a JavaScript property of a different name than the HTML attribute name.

  • Anonymous
    March 18, 2009
    Oh, you're quite right, I misread.  My bad.

  • Anonymous
    March 18, 2009
    Incidentally, though, those aren't standards.  With all the void main() floating around MSDN, you should probably keep view of what you're citing for code quality.

  • Anonymous
    March 18, 2009
    @H, tomasj, Chris, John Haugeland: Using elm.className will still work as expected in IE8 Standards Mode. The change I mentioned only affects methods for working with DOM attributes, such as getAttribute(). This change makes IE8 Standards Mode match the behavior of other browsers in this scenario.

  • Anonymous
    March 18, 2009
    Web ASP.NET MVC 1.0 Released! - Download – SourceCode Microsoft SuperPreview - a New Way to Test Websites

  • Anonymous
    March 18, 2009
    Thank you for submitting this cool story - Trackback from DotNetShoutout

  • Anonymous
    March 18, 2009
    Thanks for clarifying the change to getAttribute around className. But above you mention "SOLUTION: Use the standardized name, "class"... " and on msdn ( http://msdn.microsoft.com/en-us/library/ms536429.aspx ) it says "When retrieving the CLASS attribute using this method, set the sAttrName to be "className", which is the corresponding Dynamic HTML (DHTML) property." This doesn't quite match up, or am I misreading this?

  • Anonymous
    March 18, 2009
    see: http://www.microsoft.com/Presspass/press/2009/mar09/03-18IE8AvailablePR.mspx Hurray! Harry

  • Anonymous
    March 19, 2009
    So IE8 has now made it to Release Candidate 1 (RC1), meaning that it will very shortly be in the hands

  • Anonymous
    March 19, 2009
    So IE8 has now been released, meaning that it will very shortly be in the hands of users for just browsing

  • Anonymous
    March 19, 2009
    @Dan - "Aaron, your assumption that /any/ bug requires only "a 30 second to 5 minute fix" suggests that you know very little about professional software development." Obviously you don't know much about this either.  Fixing a method that is already implemented like this one isn't that hard. In pseudo code: public NodeList getElementsByName(name){  nl = new NodeList();  atts = List("id","name");  for(att in atts){    nl.add(this.getElementsByAttMatch(atts[att], name, CASE_INSENSITIVE) );  }  return nl; } which changes to: public NodeList getElementsByName(name){  nl = new NodeList();  nl.add(this.getElementsByAttMatch("name", name, CASE_SENSITIVE) );  }  return nl; } Ok, so psuedo code is a little less complex than C/C++ or whatever IE is written in but come on - this is not rocket science. For any developer working on IE that can't fix the internal code for this method in less than 5 minutes?... I can only say that maybe they aren't qualified enough to do the fix.

  • Anonymous
    March 19, 2009
    I can no longer edit offline webpages on sites under development while 'viewing source on the fly' using notepad. Instead I am presented with a page that affords no access to the code to be edited other than view, copy or print. What solution do you suggest before I remove IE8 as a detrement and inferior product for hand code developers.

  • Anonymous
    March 20, 2009
    @makatak, Click Tools > Internet Options and select the Programs tab. Change the "Html Editing" option to Notepad (if that is really what you want to use). When you open a local file instead of clicking on View Source click the Page menu (Alt+P) and select "Edit with Notepad".

  • Anonymous
    March 20, 2009
    @makatak, another option instead of using the "Edit with" menu item is to change which program is used for "View Source". To do that start RegEdit.exe and navigate to: HKLMsoftwaremicrosoftInternet Explorer Create a subkey named "View Source Editor" (without the quotes). Within this key create a string value named "Editor Name" (again without the quotes) and set its value to Notepad.exe

  • Anonymous
    March 20, 2009
    The comment has been removed

  • Anonymous
    March 20, 2009
    @H: You're right, the MSDN documentation doesn't match up. We're working to update it to reflect the correct syntax for IE8 Standards Mode.

  • Anonymous
    March 21, 2009
    A simple script that works correctly in IE5.01 thru IE7 and all the other browsers including FF3.1b3, Safari4, Opera10 and yet fails in IE8 can be found at:- http://chartermanmarine.co.nz/test/vertical-align-ie8.html Probably, at the end of the day it has nothing to do with the script, but rather a rendering issue associated with the onResize event-handler - click Restore Page Down/Up and it works in IE8. Surely this, and the many other instances already pointed out by contributors to this blog, places IE8 in the rather enviable position of "leading the pack" but where to?  

  • Anonymous
    March 22, 2009
    Reports of broken sites are an important part of the feedback the IE team receives from the community. When we receive a report of a broken site, we take it and identify the core issue causing the problem. A number of these issues end up being side effects

  • Anonymous
    March 22, 2009
    Can anybody explain, what exactly happened to "innerHTML"? I mean, I was writing it like this: "document.getElementById(id).setAttriute("innerHTML", newValue);". This doesn't work in IE8. Writing "document.getElementById(id).innerHTML" does, I just don't get the difference. Some other attributes (haven't checked on all of them), say, "value", do get set with setAttribute. getAttribute works as it did.

  • Anonymous
    March 22, 2009
    Sorry, fix. "getAttribute" doesn't behave the same, either.

  • Anonymous
    March 22, 2009
    @barsik "document.getElementById(id).setAttriute("innerHTML", newValue);" should have NEVER worked, because innerHTML is no Attribute, but an property of this Object. This is not the same.

  • Anonymous
    March 24, 2009
    Microsoft released the final version of IE8 last week (3.19.2009); your users will soon be automatically upgraded unless auto-updates have been explicitly blocked. Are you ready?...

  • Anonymous
    March 25, 2009
    Can we PLEASE have some indicators as to what tests IE8 carries out to decide whether or not to jump into compatibility mode? The first page that I tested on my site forced itself into compat mode, even though it rendered better in standards mode, and I have no idea why it went into compat mode in the first place.

  • Anonymous
    March 25, 2009
    @Mike: There are two cases: 1> Your site is on the compatibility list, or 2> IE encountered a fatal rendering problem when visiting your site.  #2 only occurs if the option inside Tools / Internet Options / Advanced is enabled; when it's disabled, a fatal error will show a blank page with no context menu. When #2 occurs, the page begins to render in standards mode, then automatically refreshes in the middle in IE7 mode.  #2 is never meant to be encountered in the wild (and we fixed the significant majority of these after RC1) so if you can provide the URL of your site, we'd love to have a look.  thanks!

  • Anonymous
    April 13, 2009
    Since I just posted the article Web Mapping Applications Display or Behave Unexpectedly In Internet Explorer 8 , I thought I would touch on the topic of differences between IE8 Compatibility View and IE7. The Internet Explorer Team has a great post which

  • Anonymous
    April 24, 2009
    Last week we took a look at Compatibility View as a way to retain the older rendering functionality just

  • Anonymous
    April 25, 2009
    The release candidate (RC) for Windows 7 is just around the corner. Dates for the Windows 7 RC were announced

  • Anonymous
    April 28, 2009
    I was think if I should post this info knowing it’s an awful lot to read…. but it’s to important as the

  • Anonymous
    May 13, 2009
    This post is intended for IT administrators, but more technical users might also find it useful. During

  • Anonymous
    May 20, 2009
    Самые вкусные консервы их тех, которые я когда-либо пробовал Хотя эта статья адресована ИТ-администраторам,