The History of the Web logo

Unraveling the web's story

Almost (Standards) Doesn’t Count

The W3C logo

In 2008, the team at Microsoft found themselves in quite the pickle.

Let me back up.

In 2002, the team at Mozilla found themselves in quite the pickle.

Mozilla was the team inside of Netscape that had been spun out as a non-profit to work on Netscape’s browser. Netscape was, in turn, acquired by AOL shortly after. Fortunately, the source code for Netscape Navigator was open sourced, and the Mozilla Corporation enlisted the help of the community to help build itself a more modern browser.

Their crowning achievement was to be a brand new rendering engine called Gecko. It was faster, sleeker, and the most standards-compliant engine the web had seen.

As Gecko was being prepared for inclusion in the first version of Firefox (which would replace Navigator) some folks on the Mozilla evangelism team began testing it out on a small group of popular websites. They noticed something odd. A good amount of these sites appeared broken when rendered by Gecko. And not just a little.

Back in those days, sites would often splice up an image into several different parts and arrange them on a page using tables. In even the most up to date browsers of the time, this would cause the images to be “shrinkwrapped,” inserted into the table without any margins or borders, so it was easy to line up images all across a page to construct a design. The new Gecko engine followed the actual W3C specification more closely though, and made images inline by default, which left white gaps around images when added inside of tables.

A demonstration of the issue with tables and images
Kind of like this.

And that one small change broke a handful of popular sites.

There was no roadmap for how to handle an issue like this. Mozilla was coding up their browser according to actual web standards, were fixing an issue that had basically passed the web right by. Not exactly knowing what to do, they turned to developers at these sites to see if they’d be willing to make a few changes prior to the release of Gecko. Just about everyone said no. Their site was fine, they reasoned, it was Mozilla that was screwing everything up. This was understandably frustrating for the Mozilla team, but rather than keep a bug going forever, they decided to fall back on an idea that had worked in the past.

Back when browsers first made the switch to being fully standards compliant, starting with IE5 for Mac, they ran into the same issue. Developers had learned how to code around the peculiarities of browsers like IE and Netscape that weren’t standards compliant. When sites were rendered correctly, they basically fell apart. To get around that, browser makers introduced “doctype switching.” When developers used a fully standard doctype at the top of their HTML document, the site was rendered according to the latest standards. But when a doctype was absent, or an older doctype was used, things would switch to “quirks mode” which rendered sites just like older browsers, quirks and all.

Mozilla uncovered the doctype these sites were using and added a third rendering mode to the mix, which they called “almost standards” mode, built I would add, entirely to placate a few sites at the top. It laid out sites almost 100% according to standards, except for that one specific bug with images in tables.

Ok, so let’s get back to Microsoft. Because in 2008, they found themselves in a similar situation. Well, it was a little different. This is what happened. After quirks mode, there was a big push in the web community, and by the Web Standards Project, to get developers to use the “standards mode” doctype which, in modern browsers, would keep things future proof and generally keep the web moving forward.

Here’s the problem. Internet Explorer 6 didn’t include two different modes. It never got a standards mode because it didn’t get an update at all for years and years. So every website on IE6 was rendered in “quirks mode”. IE6, though, was the web’s most popular browser. Two things happened. A lot of developers heard that it was a good idea to add a doctype to the top of their page to set it to “standards mode,” so they went ahead and did that. But then, they only ever tested their sites in IE6.

Developers would code up their pages around and with the bugs that were present in IE6, which was “quirks mode,” all along thinking that they were actually in standards mode because they added the right doctype. So when IE7 came out, and it finally did support standards mode, lots and lots of sites all of a sudden just broke.

Determined to ensure that they did not “break the web” again, Microsoft decided to do things a little different for Internet Explorer 8. Working alongside standards advocates, they came up with what became known as “version targeting,” an IE specific meta tag that explicitly told the browser how to render a page. It looked like this:

<!— render in IE 8 mode —->
<meta http-equiv="X-UA-Compatible" content=“IE=8">

<!— render in IE 7 mode —>
<meta http-equiv="X-UA-Compatible" content=“IE=7”>

Using the X-UA-Compatible meta tag, developers could specify exactly which browser to render the page with. So with a value of “IE=7”, even if the browser itself was Internet Explorer 8 or 9, it would still render with all the quirks and oddities of IE 7 bundled in. That way, if you found that your site was breaking apart in the newest version of IE, you could easily toggle the site to an older rendering version until you had a chance to fix the issues.

Screenshot of Internet Explorer 8 upon its release

In practice, this got IE into a bit of a Russian dolls situation, since every new release of the browser also needed to include every previous release bundled in. And as an added layer of protection, Microsoft announced that by default it would render pages in IE7 mode, meaning to actually get up to date standards features, you would explicitly need to add an IE8 meta tag.

Aaron Gustafson announced the version targeting fix in a post on A List Apart on January 21, 2008. By January 22nd, there were dozens of opinions in the mix, a little from column A, a little from column B.

Those who were for it argued that in many ways, the web had painted itself into this corner. The toggling of versions might cause some issues down the line, but Microsoft was faced with a tough decision. Internet Explorer was the most popular browser at the time, and this offered a real-world solution that protected the web from breaking all over again.

Those against it believed that Microsoft was simply continuing its tradition of holding the web back (not to mention the possible legal ramifications of the “lock in” to specific versions of IE it caused). They did the same thing when they refused to update IE6. This was just one more example of the latest HTML and CSS features held back from the general public by a company afraid of change. A problem only compounded by the fact that the default mode would be revert to an older browser, holding the entire public back from getting the advancements of the web.

Things went back and forth between the Microsoft team, WaSP, and the rest of the web community. The conversation got a bit messy, but thankfully, there was a conversation. Ultimately, Microsoft decided that it would keep the meta tag, but remove the default behavior so the latest standards were rendered by default. In the end, it was a compromise that most could live with.

It’s important to understand that the development of the web is a push and pull. We don’t always (or I’d say rarely) get it right the first time. In our most powerful moments, the web community opens itself up to changes. It accepts compromise and course corrections. And when all else fails, we fight on behalf of our users. Because, really, what else matters?


Leave a Reply

Your email address will not be published. Required fields are marked *