Running today’s different markup
I want to follow-up on comments from a previous post that asked questions about how many modes and rendering engines are in IE9. It’s worth noting that all browsers have multiple modes. This post is about the different modes in IE9 and the scenarios they accommodate.
First, there is IE9’s Standards mode. It is IE9’s most standards-compliant, interoperable and fastest mode. It includes support for SVG, CSS3, DOM Level 3, and many other standards-based features. This is IE9’s default mode. We want site developers to use this mode as part of getting us all to the goal of running “same markup”. To see IE9’s Standards mode in action, check out the examples on the IE9 Test Drive site.
Many real world sites still rely on legacy modes. IE9 supports Quirks modefor sites such as atlaspost.com, chase.com, and zapak.com. The lack of doctype on these sites indicates that they want to render in Quirks mode. As Peter-Paul Koch points out with a set of test cases, markup that relies on Quirks mode behavior doesn’t always render as intended in other modes.
For example, here’s unibanco.com.br in Quirks mode:
And the same site in IE9 Standards mode:
Some site developers have legacy code similar to this that relies on the behavior of Quirks mode across browsers. IE9 continues to run this markup.
So far we’ve covered IE9’s Standards mode (the most standards-compliant mode) and Quirks mode. There are other sites that rely on IE7-specific behaviors. For example, aapeli.com targets IE7 specifically with its CSS:
<!--[if IE 7]>
<link href="https://st1.esp.playray.net/themes/ie7.v28494.css" type="text/css" rel="stylesheet" />
<![endif]-->
To make sure that IE9 continues to “just work,” IE9’s engine supports both IE7 Standards mode and IE8 Standards mode. Without these modes in IE9, site developers would have to go back and re-work sites that relied on specific behaviors.
Ultimately we want the same markup to work across all browsers. In the meantime, we want the markup you wrote for IE7 and IE8 to continue to work in IE9. Site developers can add the X-UA-Compatible meta tag or HTTP header to give themselves time to update their sites to use the same markup across browsers.
IE9 supports the four modes described in this post: IE9’s Standards mode (the most standards-compliant mode), Quirks mode, IE7 Standards mode and IE8 Standards mode.
Same markup
Writing sites so that the same markup runs in as many browsers as possible is important. Many sites today use feature and behavior detection to work across browsers and legacy IE versions. Here’s an example from weather.com that shows how IE9 executes the same standards-based markup for DOM Level 2’s getComputedStyle while IE7, IE8 and IE9’s legacy modes will execute the legacy currentStyle markup:
As the above example shows, it’s a good practice to write standards-based markup first and fallback to legacy markup. Stay tuned for a post that describes feature and behavior detection across browsers in much more detail.
To summarize, IE9 is optimized to display sites according to standards so developers can use the same markup. It is also able to display sites in legacy modes if site developers specify that. This means users can continue to use the web and web developers can move forward according to their own schedules.
One of the places where we’d like your feedback is the consistency between IE8 and IE9. For example, are there differences between IE7 Standards mode in IE8 and IE9? Are there differences between the standards-compliant features we shipped in IE8 and the same features in IE9? Check out the Platform Preview and let us know.
Thanks!
Marc Silbey
Program Manager
Comments
Anonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
The comment has been removedAnonymous
January 01, 2003
@Wurst: some people just love saving an image to JPEG, then resaving it as PNG. But the IE blog team did better before, such as saving an image as BMP then renaming it to PNG (at least there was no quality loss there...). I guess that shows the managers here haven't kept up with technology from 20 years ago. That is, if they ever were technicians.Anonymous
January 01, 2003
HTML 5 test: Chrome 5.0.375.3 -> 142 / 160 Opera 10.50 -> 102 / 160 Firefox 3.6.3 -> 101 / 160 Safari 4.0.5 -> 70 / 160 IE 8.0 -> 24 / 160 IE 9 P. -> ? (HTML5-conformant whitespace handling is not yet implemented.) http://html5test.comAnonymous
April 13, 2010
Not sure what the conditional comment example is trying to say, but I guess IE9 won't render the content inside the IE7-specific conditional comments in aapeli.com right?Anonymous
April 13, 2010
Do you guys have any plans to support VP8 for HTML5 video? It's being open-sourced. http://newteevee.com/2010/04/12/google-to-open-source-vp8-for-html5-video/Anonymous
April 13, 2010
starks: "open-source" doesn't mean "free from patents and safe to use." It's all about the lawyers.Anonymous
April 13, 2010
The comment has been removedAnonymous
April 13, 2010
I really hope that you will also remove the user options to activate backwards compatibility modes, including user's list of sites in compatibility mode, Microsoft's list of sites in compatibility mode, option to display all intranet sites in compatibility mode and option to display all all sites in compatibility mode. This way web developers could be sure to always get the best mode using "same markup", that is without needing the IE-specific X-UA-Compatible.Anonymous
April 13, 2010
Dear Microsoft, please stop trying to accommodate people who can't design web sites properly. The best way for everyone to use the "same markup" is by making it known who those people are who are too lazy to learn XHTML!Anonymous
April 13, 2010
The comment has been removedAnonymous
April 13, 2010
In an earlier post on this blog it was usggested that IE would support rendering of two former browser versions Wil IE9 be the last browser to support IE7 mode?Anonymous
April 13, 2010
@hAL,: that could be, but then there are discrepancies: When Windows 8 comes out (with IE 9), Windows XP (and 2003) will be on extended support: IE 6 mode won't be supported (funny how it never, ever was, eh?), and XP won't get IE 9, IE 9 will support 7 and 8 render modes. When Windows 9 comes out with IE 10, Vista will be one year away from extended support: so, IE 10 will be the last version Vista will support, and will support 8 and 9 - but not Vista's original rendering mode, IE 7! The way I see it, an IE version will support the rendering modes of whatever IE version that is shipped with a still supported version of Windows - with the addition of IE 5(.5) mode, AKA Quirks mode. I'll add that the website used as example doesn't even fall in the Render Mode discussion: it's Pure Tag Soup (tm). I hadn't seen such ugly markup since I cleaned up a Word-made HTML page...Anonymous
April 13, 2010
Sigh. Microsoft keeps insisting on letting bad code work. It's bad enough when you unleash a plague on an industry. It's worse when you do everything in your power to perpetuate it.Anonymous
April 13, 2010
The comment has been removedAnonymous
April 13, 2010
Hey, Mitch 74 You are wrong in your flawed conclusions. Read this again: "IE9 supports the four modes described in this post: IE9’s Standards mode (the most standards-compliant mode), Quirks mode, IE7 Standards mode and IE8 Standards mode." The quoted "Quirks mode" is actually the IE 5's way of rendering web pages, which was also used in IE6.Anonymous
April 13, 2010
el.ownerDocument.defaultView.getComputedStyle is just useless indirections. Just window.getComputedStyle is what the code needs.Anonymous
April 14, 2010
The comment has been removedAnonymous
April 14, 2010
HTML 5 test: Chrome 5.0.375.3 : 142 / 160 Opera 10.50 : 102 / 160 Firefox 3.6.3 : 101 / 160 Safari 4.0.5 : 70 / 160 IE 8.0 : 24 / 160 IE 9 P : HTML5 conformant whitespace handling is not yet implemented ! http://html5test.comAnonymous
April 14, 2010
@Andy: The problem with exposing "new" methods/capabilities to legacy modes is that it can break sites that would otherwise work. Several major sites were broken, for instance, when we tried to expose the new "native" JSON object in IE7 emulation mode, because their script-implementation of the JSON object didn't match the ES3.1/5 definition of that object. So when the new native object was exposed, they wouldn't hook up their own implementation and they would proceed to fail when calling non-existent methods on the native version.Anonymous
April 14, 2010
@wechrome: Right, IE9 won’t render the IE7-specific conditional comment by default. An exception to this is if the site is in Compat View, which means that the site is running in IE7 Standards Mode. @hAl: We would love to see developers transition their sites to run best in the latest Standards mode so that future IE versions don’t need to support IE7 mode.Anonymous
April 14, 2010
A poorly compressed PNG with JPG compression artefacts. Is this to underline the fact the image shows a poorly written website?Anonymous
April 14, 2010
@Mitch74 >Quirks mode includes many, many quirks; it's up to the browser maker to decide what quirks, how and when they apply, etc. Browser manufacturers do not have to decide or discuss what should be in quirks mode. What goes into quirks mode is anyone's decision. > No browser HAS to provide Quirks mode. Agreed. > Browsers now tend to implement the same quirks I do not think so. There are lots of differences. Jukka Korpela and Peter-Paul Koch documented these differences. > but there was a time when Quirks mode meant one thing for a browser, and another for the others. Whether you are right or I am right on this particular point should not stop Microsoft/MSDN/IE Team from encouraging web authors to upgrade their markup code. The best solution for everyone involved (web authors, browser manufacturers, web visitors of sites) is still to create valid and compliant code (markup and CSS) with a doctype referencing a strict DTD. regards, GérardAnonymous
April 14, 2010
"Browser manufacturers do not have to decide or discuss what should be in quirks mode." heh. it must be a funny little world you live in, where software isn't the product of its makers' decisions.Anonymous
April 14, 2010
"We would love to see developers transition their sites to run best in the latest Standards mode so that future IE versions don’t need to support IE7 mode." - MarcSil [MSFT] Does there not come a point where you can exercise the power you have and say "Right guys, we've given you 10+ years of leniency, enough is enough"? Surely, as a business decision, it would be more efficient (profitable even) to concentrate on as few rendering modes as possible?Anonymous
April 14, 2010
The comment has been removedAnonymous
April 14, 2010
Gary, Microsoft is big, but the web is bigger-- Microsoft cannot force the web to update, even if they warned them in advance (go read about the IE7 Strict Mode change debacle that prevented adoption of IE7 for years). Users will not install browsers that aren't compatible, so everyone loses.Anonymous
April 14, 2010
The comment has been removedAnonymous
April 14, 2010
oddly enough I'm caught between a rock and a hard place. I work on a legacy application that has 1000s of users. The application runs in quirks mode and would literally take a dedicated team 12months of solid effort to revamp the whole application to standards mode. I desperately want to make the switch but it is hard to justify at the business level based on the $$ to be spent just to get to square one again (but in standards mode) I love that IE9 will be even more standards compliant but when I think about it -- even if I get the app to work in a year I'll still have to handle "standards" mode in IE9, IE8, IE7, and IE6 - not a test matrix I look forward to. On a personal level and on previous projects I was and am a die-hard standards advocate yet in this case with this project I'm forced to accept defeat and continue on in quirks mode. For those that will reply there is no way it would take a year - I'm quite serious (and have converted other huge projects in the past) it just isn't modular code that can be cleaned up easily in pieces.Anonymous
April 14, 2010
@Menace: you don't know the size of Jill's project. Due to the extensive work AND testing required(and probably, relying on outdated ActiveX controls that NEED Quirks mode, with all the proprietary DOM... nonsense of IE 5.x), spending a year to convert a huge infrastructure would indeed be a possibility.Anonymous
April 15, 2010
I'd gladly change my legacy sites to IE9 Standard's mode. However, the biggest problem is that IE8(9?) does not default to "px" when CSS width,height,left,top have no units specified. It requires a tooth-grinding process to place many 1000's of "px" at all values, plus modify code that sizes/locates on unitless values. I think IE8 overshot the mark when it became too strict on this point. If IE9 backs off this requirement, then I would arrange my sites for IE9 Standards mode.Anonymous
April 15, 2010
The comment has been removedAnonymous
April 15, 2010
Slight correction: the getComputedStyle() function shown here may have been found on weather.com, but it's actually part of the YUI Library's DOM utility (from YUI 2): http://github.com/yui/yui2/blob/master/src/dom/js/Dom.js#L133-139Anonymous
April 15, 2010
The comment has been removedAnonymous
April 15, 2010
@Francis: IE 8 does as other browsers do: no unit to a CSS value other than 0 => ignore property. IE 7 did default to 'px', but than ran contrary to the standard and to what other browsers did. Fast fix and solution: use CSSTidy. Done.Anonymous
April 16, 2010
@ John A. Bilicki III A correction is in order: the Pacific ocean is surrounded on ALL sides by active subduction zones, which means, that NO island will wander further out into the Pacific, but rather right towards its next subduction zone, where it will be swallowed sooner or later. The highway you spoke of would in fact become shorter and shorter, until a few miles out in the ocean the island will disappear and turned into molten lava. Cheers HarryAnonymous
April 17, 2010
@Mitch 74 Re: default "px" and CSSTidy I've tried all the so-called validators. None of them add "px" to unitless style values. This indicates the default "px" should be OK for the browser. I think this hard-core stand that a browser default "px" is mortal sin, is goofy. This is the primary impediment for legacy sites to migrate to full standard compliance.Anonymous
April 17, 2010
Before flaming the heck out of Francis' "I think following standards is goofy" remark, please keep in mind that there are many many thousands of developers who probably agree with him. Fortunately, the browser teams are all moving toward standards and away from the "whatever works" mentality that existed before, so it would probably be a better idea to help educate Francis about why standards are worthwhile to be "hard-core" about than to simply flame him as others here are wont to react.Anonymous
April 18, 2010
The comment has been removedAnonymous
April 18, 2010
I think you mean the Aleutian Islands, and we're drifting a bit off-topic now, aren't we?Anonymous
April 18, 2010
@EricLaw [MSFT]: "The problem with exposing "new" methods/capabilities to legacy modes is that it can break sites that would otherwise work" I totally get that. That's why in my comment I suggested an opt-in mechanism that switched the script engine only, without switching the rendering engine too. For instance, I might write the following at the top of my script: "ScriptingEngine=IE9"; This is similar to ECMAScript 5th's "use strict"; It would allow me to opt in to using the IE9 standards mode scripting features if they were available. Any other engine would parse this as an unassigned string. Honestly, I'm happy for any solution you guys can come up with that doesn't involve me having to write different CSS files and conditionally include them based on the running IE version, just so I can make use of native scripting features.Anonymous
April 18, 2010
@Francis: are you talking tag attributes (width="30") or CSS (style="width:30px") ? The two are different. Tag attributes are unitless - they are expressed in pixels. CSSTidy isn't a validator, it's a corrective tool - it DOES add missing units (or removes extraneous ones). CSS styles (you did define that the style attributes used are of the MIME type 'text/css', didn't you?) must have units = except if they are = 0.Anonymous
April 18, 2010
@Andy: You're right that making an "opt-in" version of the scripting engine would reduce the compatibility impact, although it would double the testing impact, and it would only fuel the critics who argue that "enhancing" support for legacy document modes "holds back the web." More importantly, I don't think a script-engine switch alone would really give you as much that you're hoping for, since the DOM itself is responsible for so much of the developer experience when running JavaScript. The DOM is tightly-bound to the layout engine, and could not be provided alone.Anonymous
April 19, 2010
How ironic that the company who created this mess now tells us how to handle it.Anonymous
April 21, 2010
All browsers have multiple modes? Standards mode and quirks? Almost standards doesn't even belong on that list but doesn't IE8 have like 9 different modes altogether? And aren't most of those strictly IE related and have nothing to do with web standards? Yes, I believe so.