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 mode for 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:

unibanco.com.br in Quirks mode looking fine.

And the same site in IE9 Standards mode:

unibanco.com.br in IE9 standards mode with many elements out of place.

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=”http://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:

code sample from weather.com.  The site detects for the getComputedStyle functionality before falling back to legacy currentStyle.

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

  1. Anonymous says:

    @Starks: I don’t see Microsoft adopting a codec they didn’t develop any time soon (just look at the h.264/VC-1 mess)

    @Matt: VP8 isn’t exactly new. Depending on the open-source license (say, GPLv3), the code’s creator can’t enforce patents on the Free software it publishes. Of course, that leaves submarine patents – but those are a problem shared by closed and open source software.

    @Gérard: X-UA-Compatible is enough of a mess without trying to do a balancing act between the page’s DOCTYPE and that override (since it IS an override). Now I agree that it can be disconcerting, but on the other hand:

    – websites using X-UA-Compatible are probably not too old or badly maintained; there is a chance they don’t trigger Quirks mode anyway.

    – Quirks mode includes many, many quirks; it’s up to the browser maker to decide what quirks, how and when they apply, etc. No browser HAS to provide Quirks mode. Browsers now tend to implement the same quirks, but there was a time when Quirks mode meant one thing for a browser, and another for the others.

    @Jesper: that would be unrealistic.

    @Marc: I think the comments you refer to were complaining about the parallel presence and required support for IE 5,6,7,8 ( and 9) caused by:

    – Windows 2000’s lack of support for any version more recent than 6

    – Windows XP’s lack of support for any version more recent than 8

    – continued support for all these versions in parallel…

    All these reasons mean that we (web developers) need to support 4 versions of IE simultaneously (not helped that these versions have little in common, or with the other browsers – IE 9 is a bit of a relief, for that matter, even though the preview currently has quirks), while other browsers, well… I wonder who still checks his website under Firefox 2 or Opera 8, for example.

    I would still like IE9 more if there was:

    – support for pageX/Y (still no answer to that)

    – stricter XML parsing (AFAICS it will be fixed Real Soon Now(tm))

    – more explicit messages on innerHTML errors (‘unknown error’ doesn’t cut it, please at least try for ‘DOM error’)

    – along with the above point, links to MSDN articles describing the property – and fixed up MSDN articles, with valid code! Ask the guys there to run JSlint on their Jscript, for example.

  2. Anonymous says:

    @jill Microsoft’s to blame. they made everyone go jack%#&* with their coding style, usually seen in ASP programmers too. "plain" sloppy, non-D.R.Y. code, and of course, non cross-browser.

    even if it’s a huge project, I can assure it can be done properly, with much less repetition, and using existing javascript libraries for the tough work of cross-browsing. I know because I converted a 7 months big project from HTML 4 and CSS1 to HTML5 and CSS3 in a matter of 2 months. And wow, the result is fantastic. Of course, I ask my clients to use good browsers, and do the opposite that Microsoft did, ask only to use IE. When the clients try Firefox or Chrome for the first time, they are kinda lost, but they quickly realize how fast other browsers are, and thus more productive.

    Had this big law firm using Windows XP, no service pack at all, in all machines, and of course, the dreaded IE6. I offered a change, in exchange money + for some services. They never needed another browser other than Chrome, and are pretty satisfied with an AJAX version of their old crappy IE6 system.

  3. Anonymous says:

    What about you guys smoke a huge c0ck?

    http://www.kinkinfo.com/kinkconnect.jpg

  4. Anonymous says:

    God, if I read about interoperable once again in this blog, I’m going to kill myself.

    You’re failing again IE team

  5. Anonymous says:

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

  6. Anonymous says:

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

  7. wechrome says:

    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?

  8. Starks says:

    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/

  9. Matt says:

    starks: "open-source" doesn’t mean "free from patents and safe to use."

    It’s all about the lawyers.

  10. @Marc Silbey [MSFT]

    > Ultimately we want the same markup to work across all browsers.

    >  IE9 is optimized to display sites according to standards so developers can use the same markup.

    Again, for the nth time, it’s not just "same markup". It is same *valid* markup. As soon as the markup is invalid, then there is no certainty, no consistency, no reliability assured in all/each browsers.

    IE8’s quirks mode is not the same as Firefox’s quirks mode or Opera’s quirks mode.

    The same can be said about valid CSS code versus invalid CSS code. Error correction (parsing CSS errors) in IE7 and IE8 are very different, with IE7 being unreliable, inconsistent, very bad.

    And a doctypeless webpage can be forced into web-standards-compliant rendering mode in IE8 and IE9 thanks to the X-UA-Compatible meta-tag while other browsers would render that same webpage in quirks mode.

    Gérard Talbot

  11. Jesper Kristensen says:

    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.

  12. Evil Dr says:

    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!

  13. Mitch 74 says:

    @Starks: I don’t see Microsoft adopting a codec they didn’t develop any time soon (just look at the h.264/VC-1 mess)

    @Matt: VP8 isn’t exactly new. Depending on the open-source license (say, GPLv3), the code’s creator can’t enforce patents on the Free software it publishes. Of course, that leaves submarine patents – but those are a problem shared by closed and open source software.

    @Gérard: X-UA-Compatible is enough of a mess without trying to do a balancing act between the page’s DOCTYPE and that override (since it IS an override). Now I agree that it can be disconcerting, but on the other hand:

    – websites using X-UA-Compatible are probably not too old or badly maintained; there is a chance they don’t trigger Quirks mode anyway.

    – Quirks mode includes many, many quirks; it’s up to the browser maker to decide what quirks, how and when they apply, etc. No browser HAS to provide Quirks mode. Browsers now tend to implement the same quirks, but there was a time when Quirks mode meant one thing for a browser, and another for the others.

    @Jesper: that would be unrealistic.

    @Marc: I think the comments you refer to were complaining about the parallel presence and required support for IE 5,6,7,8 ( and 9) caused by:

    – Windows 2000’s lack of support for any version more recent than 6

    – Windows XP’s lack of support for any version more recent than 8

    – continued support for all these versions in parallel…

    All these reasons mean that we (web developers) need to support 4 versions of IE simultaneously (not helped that these versions have little in common, or with the other browsers – IE 9 is a bit of a relief, for that matter, even though the preview currently has quirks), while other browsers, well… I wonder who still checks his website under Firefox 2 or Opera 8, for example.

    I would still like IE9 more if there was:

    – support for pageX/Y (still no answer to that)

    – stricter XML parsing (AFAICS it will be fixed Real Soon Now(tm))

    – more explicit messages on innerHTML errors (‘unknown error’ doesn’t cut it, please at least try for ‘DOM error’)

    – along with the above point, links to MSDN articles describing the property – and fixed up MSDN articles, with valid code! Ask the guys there to run JSlint on their Jscript, for example.

  14. hAl says:

    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?

  15. Mitch 74 says:

    @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 ™. I hadn’t seen such ugly markup since I cleaned up a Word-made HTML page…

  16. blah says:

    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.

  17. Pat says:

    >>>Microsoft keeps insisting on letting bad code work.<<<

    You haven’t thought about this hard enough. If Microsoft ships a browser that breaks compatibility with "bad code" then normal users (who couldn’t care less about HTML-quality) will refuse to upgrade (proven by slow uptake of IE7). When they fail to upgrade, then "better" web developers don’t get to use the shiny new features on their "good" code because the new browser isn’t broadly deployed.

    To say nothing of the many cases where "bad" code cannot really be fixed (e.g. burned on DVDs, written by some vendor who will never be seen again, etc).

    Overall, you’re discovering the difference between building a real program used by nearly a billion people and designing a "perfect" system that fails to consider the environment in which it operates. The latter will fail every time.

    >>>As soon as the markup is invalid, then there is no certainty, no consistency, no reliability assured in all/each browsers.<<<

    You just don’t get it, do you? None of that is assured by "valid" markup either.

    Mark’s point is just that MS values interoperability over "standards" which is a wise choice because in cases where all of the browsers behave the same way but not like the standard says, someone gets the bright idea that maybe the standard should be fixed. Then that happens (aka HTML5) and the markup is now both interoperable AND "valid".

  18. Jr says:

    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.

  19. mors says:

    el.ownerDocument.defaultView.getComputedStyle is just useless indirections.

    Just window.getComputedStyle is what the code needs.

  20. Andy Earnshaw says:

    @Mark Silby [MSFT]:

    One of the things that really irked me about the jump from IE7 to IE8 was the lack of forwards compatibility in JavaScript from IE7.  I personally found it pretty annoying that I couldn’t write JavaScript that would conditionally use IE8’s JScript features without forcing IE8’s document mode.

    This means writing CSS for both IE7 and IE8, instead of allowing IE8 to render in IE7 mode whilst making use of new additions to JScript provided by IE8.  A big example of this is json2.js (from http://json.org).  The first line of code is

      if (!this.JSON) { this.JSON = {} }

    This checks for a native implementation of JSON and creates it if it doesn’t exist.  In IE7 compatibility mode on IE8 it doesn’t exist so the native (faster) version isn’t used.

    This was particularly frustrating when developing Windows Desktop Gadgets (that run on the IE engine), it seems like rather a lot of extra work to create multiple style sheets and use conditional comments just so we can use native JavaScript features added in the latest release.

    Mozilla allows you to choose which script engine is invoked via the script tag, for newer features.  It would be great if we could do something similar with IE — maybe in a similar fashion as ECMAScript 5’s strict mode:

      "use IE9";

    Forcing the script to use IE9 mode’s interpreter if available.

       "

  21. Ali says:

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

  22. EricLaw [MSFT] says:

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

  23. MarcSil [MSFT] says:

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

  24. Wurst says:

    A poorly compressed PNG with JPG compression artefacts. Is this to underline the fact the image shows a poorly written website?

  25. @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érard

  26. Luke says:

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

  27. Gary says:

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

  28. Mitch 74 says:

    @Gérard: agreed. We could discuss the matter for a LONG time, and reach no conclusion. This kind of stuff is better off left on the W3C mailing lists anyway.

    @Jr: I was answering hAL’s comment.

    @Luke: what Gérard means is that browser makers don’t have to COLLECTIVELY decide on what goes into Quirks mode. It’s up to each browser maker to include a Quirks mode – or not – and what to put in it. They do tend to agree on the biggest points (they end up in official specs, such as the CSS content-box property; HTML 3.2 is nothing if not a ‘standardization’ of Quirks mode; so are the parts of ‘DOM 0’ that ended up defined in HTML4, mostly Transitional and Frameset if I’m not mistaken)

    @Gérard: that’s what I meant when I said browsers tended to agree on what Quirks mode included. Do note, however, that while I think most browsers agree on what to put in Quirks mode, they disagree on how to parse tag soup.

    I make a difference between the two: a Quirks mode page could be well structured, with proper attributes and values and quotes in all the correct places, with a tree-like DOM, and render surprisingly similarly from one browser to another; not so with tag soup…

    But then, you can do Standard mode tag soup too (in HTML), and end up with the same problem. That’s why I personally separate the rendering mode (Quirks/Almost standard/Standard) and the parsing (properly structured HTML, properly structured XML, HTML tag soup – there’s no XML tag soup, there shouldn’t be, it shouldn’t be supported, it’s an aberration, it eats puppies, every time someone generates invalid XML and a browser renders it God puts a kitten in a blender – I’m rambling, now, ain’t I?).

  29. Luke says:

    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.

  30. Menace says:

    Does all this matter? NO, because 65% of the market will never see this "great" 5 modes compatible interoperable HTML5 capable IE

    And yet, you released the freaks to the public (all IE’s so far), and it will still be ages before people start leaving XP without a service pack for Windows 7 or 8, mainly because you wanted it this way.

    Suddenly, it’s about standards, interoperability, commitment to fixing bugs, and all the useless (for the moment) stuff, that will lead anywhere, simply because, people will be using Chrome, Firefox, Opera, with all the great features such as HTML5 and CSS3 in Windows XP without any problem, while you’re dreaming having people update an entire OS for a more or less browser that will be IE9 when it’s released.

  31. jill says:

    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.

  32. Mitch 74 says:

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

  33. Francis Hemsher says:

    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.

  34. Commentary says:

    Francis says "Please accept invalid markup."

    Umm… no.

  35. Ryan Grove says:

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

  36. The first thing I want to say and already know the quiet reply to is let broken sites break. Of course the silent reply would most likely be that such companies wouldn’t be pleased with Microsoft by having to spend money to hire *COMPETENT* web designers. In an analogy if plate tectonics moved at a foot a day instead of a centimeter a year or so then supporting sites with junk "code" would be like an island moving further out in to the Pacific ocean each day and dumping millions of tons of sand to maintain a highway to that island from the continent; at some point it’ll become absolutely futile.

  37. Mitch 74 says:

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

  38. Harry Richter says:

    @ 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

    Harry

  39. Francis Hemsher says:

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

  40. Ted says:

    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.

  41. @Harry Richter

    An island in the Pacific ocean is not inherently going to be physically located on the Pacific plate; the Allusion Islands and Vancouver Island are just some examples. Also while the subduction zones around the Pacific are extensive there are large swaths of rift and especially transform zones in areas including the Canadian west coast as well as the California coast.

  42. Matt says:

    I think you mean the Aleutian Islands, and we’re drifting a bit off-topic now, aren’t we?

  43. Andy Earnshaw says:

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

  44. Mitch 74 says:

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

  45. EricLaw [MSFT] says:

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

  46. Roel says:

    How ironic that the company who created this mess now tells us how to handle it.

  47. Rob says:

    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.