As we have blogged about
many
times, one of our top goals for IE9 is enabling developers to utilize
the same markup and code (HTML, CSS, and JavaScript) across all modern browsers. Part of
enabling the same markup means changing existing Web platform behavior for standards-compliance
and interoperability. We have published and updated the list of changes to the platform
in the IE9 Guide for Developers
along with platform previews so that developers have an opportunity to try new features
and test early and often.
We carefully designed and implemented new platform features to ensure existing sites
continue to run well in IE9’s Standards mode. As a result, for many Web developers,
no additional work is required to prepare for IE9.
For sites that need to update, we have identified a set of changes more likely to
impact existing code that does not use
feature and behavior detection. These changes are documented in the
IE9 Compatibility Cookbook, which we will continue to update based on
your feedback. For your convenience, we have listed the changes with a higher probability
of impact below. Refer to the IE9 Compatibility Cookbook for in-depth information
on these changes.
Differences between IE9 and IE8 Standards modes
- Text layout
now uses sub-pixel positioning - Angle Brackets
Are Not Allowed in the createElement Method - Function
pointers to methods require “.call” or “.bind” - Default
User-Agent (UA) String Changed - APIs Are
Not Available if iFrame Is Removed from DOM Tree - OBJECT
fallback is included in DOM and matched by window[name] - Certain
dynamic VML patterns are no longer supported - Indirect
‘eval’ function calls evaluate in global scope - Table Object
Model Is Now More Consistent with Other Browsers - Thai and
East Asian font sizes are properly respected so text may look smaller in IE9 - Content
attributes and DOM expandos are no longer connected
Differences in IE9’s platform behavior from IE8 across all document modes
Another important goal for IE9 is ensuring that legacy
document modes continue to behave the same as they did in previous versions
of IE. The only exceptions we make are to improve overall product quality in areas
such as security.
- MIME-handling
change: text/css - MIME-handling
change: text/plain - MIME-handling
change: X-Content-Type-Options: nosniff - JavaScript
property enumeration order has changed
If you are updating your site from IE7 mode, you may also want to look at Tony’s
Site Compatibility and IE8 post.
Help Us Help You
If you think we’re missing a compatibility topic or one needs additional information,
please contribute through the
IE9 Compatibility Cookbook site.
—Tony Ross and Marc Silbey, Program Managers, Internet Explorer
Thanks for compatibility mode – you've managed to make a single browser that emulates the brokenness of two at once. awesome.
So what about the broken .innerHTML setter?
What about document.all still not being evicted from the document?
What about elements with content id/name attributes auto-magically becoming members of the global namespace so that namespace collisions are a royal PITA to deal with?
When are these items going to be fixed (innerHTML), or removed (document.all, auto-globals)?
Oh and if you haven't heard it enough yet, the font rendering is atrocious.
mark
Oh, and PS I had to submit this blog form with Firefox because IE9 doesn't work on this blog. Pretty sad when you think about it. I would have figured that fixing this blog would be the #1 item. Please get off of C.S. You rode it out longer than anyone expected… please give up and install real, working, usable blog software.
Honestly, why compatibility mode? There is NOTHING compatible about compatibility mode. Sites look worse with your "compatible" mode than without it. Why don't you please just get rid of it and make your browsers compatible to begin with? Awful
Before telling people how to code, fix IE9 64bit first.
I've been getting numerous complaints from people being thrown into a crippled compatibility mode because sites couldn't be rendered. Even worse is that when forcing X-UA-Compatible edge people would just be shown blank pages, guess they have incompatible hardware, let's hope those people aren't stuck on a broken browser.
My IE9 brings my PC to 50% CPU and prevents the page from displaying when I go to a page that has an old css
FILTER: dropshadow(offx=2, offy=1, color=#666633);
Removing that code from the css allows the browser to work again.
@EricLaw [MSFT] Hello again! On blogs.msdn.com/…/internet-explorer-9-network-performance-improvements.aspx I had made a suggestion for smartscreen filter reporting url page. When you report a url it has the url of the site you was on when you clicked report to smartscreen filter. But I think the url field should be editable cause users may have the malware url but clicked out of the webpage before clicking report url. So the url field should let us input the url of the badware site.
posted from IE9.
For 12 years I've avoided coding anything into my projects that use anything but straight HTML4 CSS2 code on the client side. Back in the 90's I drove myself nuts trying to get client side stuff to work browser agnostically never mind that coming from a C background, I found the loose rules on writting Javascript to be really anyoying. so I happily jumped on server side technologies and left it to the framework or server to figure out what HTML to emit so I left, Javascript, complex CSS and cookies behind. My stuff may not be as pretty as some but it works rock solid and pays the bills. Today I'm starting to get back into the client side again and am happy to say that all I had to do to make my sites work the same was stop declaring the IE version and specific dtd in the doc type. So, for me its <!DOCTYPE HTML> and the X-UA-Compatible content="IE=edge" which looks identical on Chrome, Firefox and IE. The only client target I want to worry about now is whether I'm sending to a desktop browser or mobile device which is going to be the next compatability nightmare. Can we stop targeting specific versions of the browser??? OK, rant over.
Is there a machine image with IE9 that we can use from the Mac? VHD images can be converted to work with Parallels or Fusion. Can you guys publish one. Thanks.
@John (the first one, not cambpell)
You think you know what compatibility mode is, but you are completely wrong. It exists to make OLD websites work, not to make new websites look nicer. They've already made IE9 compatible, that's why they have compatibility mode for websites that aren't compatible with the modern web. If a site works on modern browsers, compatibilty mode isn't needed and will likely make it uglier.
Hey, what's the logic behind different colors of tabs? Some of them are greenish, yellowish and others are bluish! also can i cusotmize these colors. you see i like gray tone. can ie9 reflects my kind of colors?
@prior semblance
I'm taking about IE7 and 8 rendering my website and forcing compatibility mode when there is no reason to do so. Yes appropriate doctype's are declared. Sometimes it forces my websites in to compatibility mode and sometimes it doesn't. It's a worthless tool, and the laughing stock for a lot of people here. You're right, it's meant to make the old sites work in newer browsers, but then why is it rendering my new site properly developed into "compliant mode". Nothing compliant about it, it takes a perfectly good site and screws it up, courtesy of microsoft's terrible browsers.
@ieblog, please consider solving the issue with the SVG+XML object on this page => sputnik.googlelabs.com/compare. The problem persists because the XML DOM is not ready for setProperty function call. The script crashes at:
if(this.type == "script") doc = this._xml;
…
else if(this.type == "object")doc = this._svgObject._xml;
…
doc.setProperty("SelectionLanguage", "XPath"); <– HERE
more on this issue is at: connect.microsoft.com/…/unable-to-render-svg-xml-object
@ConFused
The coloured tabs are used to show tab groups. When you open a tab from another tab, those tabs are linked and given one of several colours to distinguish them from other tab groups. You can then close a tab group or close every tab except for the tab group.
Wow, that's fantastic! I never knew that. I love the way they handled tabs management in IE9. The Ctrl+Q and this feature are awesome. It would be great if we have a way to merge the headers of the tabs, that belong to single group, into one (which would be undoable)! like happens in Opera. Thanks
This would help us buy some space in the open tabs area. Similarly, on Ctrl+Q screen if we can merge-expand the tabs belong to a group, that would again symbolize a clean UI example. Thanks IE-team
I find the new IE9 behavior of ripping out the "javascript:" prefix of bookmarklets I paste into the address bar to be BEYOND INSANE! I can't see how this improves security for real-world end users in the slightest – only P!$$!ng off developers to no end!
I do web development about 12-14 hours out of every weekday, and 4-8 out of every weekend day… so I'm pasting in bookmarklets on a very frequent basis.
Please for the love of god either DISABLE this [AIRQUOTE]feature[/AIRQUOTE] or provide it as an option in the settings that can be disabled… only advanced users will turn it off… and that's fine because only the advanced users care.
In the meantime i'll continue developing in Firefox and Chrome… 2 browsers that actually care about developers and provide the most robust tools/environment possible.
gord
Microsoft: "one of our top goals for IE9 is enabling developers to utilize the same markup and code (HTML, CSS, and JavaScript) across all modern browsers."
So does this mean that VBScript content will no longer run in any way shape or form in IE9?
PS I'm hoping that is the case, not asking for extending legacy behavior
Funny Bug
img688.imageshack.us/…/31829945.png
Where is the underline (shortcut key) over right click of a link/image?
Built in OpenSearch does not work, you can no longer add Microsoft Update Catalog or Microsoft Support search directly from the webpage
http://yfrog.com/h3ri1p
Claiming your support for standards, then talking about writing code to make things compatible with IE9, is not a support for standards.
@Rob: It is, because in the past people coded specifically for IE, and those workarounds that were needed in the past are not needed any more with IE9.
Does IE9, like IE8, refuse to render intranet sites in strict mode unless the browser settings are changed?
This has got to be the worst thing about IE8. Undeniably evil.
@Stifu: Only for you. Those bloody intranet sites have to be same compatibility nightmare as old internal apps or even comercial offerings…
@Klimax: this is irrelevant. No matter how bad old intranet apps are, or how hard it is to be compatible with them, is not excuse not to honor the X-UA-Compatible setting for intranet sites (I mean, it was created for things like that in the first place: avoiding compatibility issues by explicitly specifying which rendering mode you want). So unless there are thousands of old intranet apps that misuse the X-UA-Compatible setting (although it didn't exist before IE8), then it would have made a lot of sense to make it so intranet compatibility mode doesn't override it.
Gotta love peeps like you and hAl, who try to defend every single thing MS does, whether it makes sense or not.
@X-UA-Compatible is only part of sollutiion. In the end what the hell is wrong? Intranet apps are hidden from internet. And generally very conservatevly upgraded. It doesn't matter whetther setting or X-UA is used,its just "solution".
And you can deactivate "compatible mode" for intrabnet so what is the deal? You get edge admins get automatic compatibility. And they don't have to change anything.(Already risky propsition…)
BTW:Defending? Just replying,while your post seemse lacking sense.
@Stifu: I think you're confused. The X-UA-Compatible declaration allows Intranet pages to run in IE9 Standards Mode, regardless of whether the "Display Intranet Sites in Compatibility View" option is enabled.
@EricLaw [MSFT]: that's not what I've witnessed or read.
Right now, I launched an intranet site which has the X-UA-Compatible meta as the first element in the head, with attribute content="IE=edge".
If I press F12, although the Document Mode is right ("IE8 Standards"), the Browser Mode is "IE8 Compat View" rather than just "IE8" (which causes rendering issues, and some more problems with Ext.Net / ExtJS). I get the right Browser Mode ("IE8") when running the site locally. I think the fact Document Mode and Browser Mode aren't dependent causes more problems than it solves.
@Klimax: although your post is hardly worth replying to, here are 2 quick points to try and enlighten you:
- The fact an internat app / site isn't available from the Internet is irrelevant. I may just want to make sure the app works consistently across browsers, and in the best way possible. From my experience, JS frameworks (jQuery, ExtJS…) and the likes tend to have bugs in compatibility or almost standard mode that are not there in strict mode.
- About disabling intranet compatibility mode: first, it's often a very big operation (the bigger the company, the bigger the operation) that is likely to be refused, or at least sure to take a long time. Also, I need some older intranet sites to stay in compatibility mode. And I'd rather control how sites need to be rendered in the site code itself, rather than asking admins to update black or white lists on all computers. And when we open some intranet sites to more countries (something common in the company I currently work at), then I should also ask their admin to configure IE the way I want it? That's not my idea of efficiency or maintainability.
@Stifu: Central management through Group policies + central list.
Frameworks of odler version have also problems on IE9 mode so compat needed. (Already spotted trouble with old DHTMLX tree control on one of websites)
->draw
Why is standards compliance touted so much and yet IE9 is still the lowest scorer of compliance of any modern browser? It seems that some of the missing features could have been easily added, such as the differeent types of input controls and validation attributes on some input controls.