Broken

I’m sure by now you’ve seen the latest issue of A List Apart. Therein, Aaron outlines Microsoft’s implementation of rendering switching based on a meta element and Eric describes how his initial feelings about the technique changed over time.

I’d like to make one thing absolutely clear. You might infer from A List Apart or from the IEBlog that there was collaboration between the Web Standards Project and Microsoft on this. That is not the case. There was collaboration between some members of the WaSP and the IE team but, as Drew makes very clear, most of us were completely in the dark about this. I knew that something was coming but I didn’t know what because Microsoft will only collaborate under NDA. That is not a good situation. NDAs are poison to free and open discussion.

With that out of the way, let me tell you what I think of the proposed http-equiv="X-UA-Compatible" instruction. I think this could have been a great feature—exactly the kind of innovation that Alex was talking about. It could have been a way of solving Microsoft’s fear of “breaking the web” for existing customers who have coded their sites to the current level of browser support—the people who understandably don’t want to have to change their sites when a new browser is released.

Here’s how the X-UA-Compatible works. In a meta element or HTTP header, an instruction such as IE=8 tells future versions of Internet Explorer to render the document as a specific version would (IE8 in this case). In theory, any future versions of Internet Explorer will retain the ability to render documents just as they would have been rendered in previous versions.

This solution was driven by the perceived problems with IE7’s release. Personally, I believe that Microsoft did a great job with IE7 but I know that within the company, it was in some ways seen as a failure. Many customers complained of IE7 “breaking” sites that worked just fine in IE6 (where “break” is usually defined as “not looking the same”). This is a legitimate source of concern for Microsoft. The proposed X-UA-Compatible header will solve this problem. Customers who don’t want their sites to behave any differently in future versions of Internet Explorer can lock down the rendering to the current browser.

So far, so good… great, in fact. But—and this is a huge “but”—if you don’t include a X-UA-Compatible instruction, you are also condemning your site to be locked into the current version: IE7. This is a huge, huge mistake.

Let’s say you’re building a website right now that uses a CSS feature such as generated content. Any browsers that currently support generated content will correctly parse your CSS declarations. Future browsers that will support generated content should also parse those CSS declarations. This expected behaviour will not occur in Internet Explorer. IE8 will include support for generated content. But unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.

I can’t believe I just wrote that sentence. This shouldn’t make any sense:

Unless you explicitly declare that you want IE8 to behave as IE8, it will behave as IE7.

That’s madness! If I don’t use the X-UA-Compatible instruction, I won’t get the benefit of any future improvements in Internet Explorer. That sounds like blackmail to me. There is an option to activate whatever is the current browser version—which, of course, should be the default behaviour. This is achieved by using the (strongly discouraged) IE=edge value in… yup, http-equiv="X-UA-Compatible". So even if you want to opt out, you have to opt in. That too is madness.

Just to be absolutely clear on this, I think that the X-UA-Compatible header is a great idea. It’s great for Microsoft. It’s great for Microsoft’s customers. But the default behaviour is wrong, wrong, wrong! This should be an innovative feature, not a mandatory part of the process of creating a document on the World Wide Web. *

IE8 has not yet been released. It’s not too late for this broken default behaviour to be changed. If enough of us make our case clearly, perhaps Microsoft will listen to us… even if we haven’t signed NDAs.

For more on this, please read


*As for all the comparisons to DOCTYPE switching, can I just point out that the reason why I put a DOCTYPE on my documents (and the reason why the WaSP lobbied authoring tool vendors to do the same) is because valid (X)HTML documents require a DOCTYPE; not because it makes Internet Explorer render in a different mode. The tail does not wag this dog. If I write a valid (X)HTML document with a correct DOCTYPE, surely I should expect a browser to render it to the best of its ability rather than crippling itself?

Have you published a response to this? :

Responses

Eric Meyer

As I’ve said, I really hope you win this argument, because I’d like to see the same default behavior. I tried and failed to make the same case; now I lay my burden down for others to pick up and carry on. Or, you know, something.

# Posted by Eric Meyer on Tuesday, January 22nd, 2008 at 6:33pm

Matt Wilcox

But you seem to miss the point that while the default behaviour certainly is wrong for any responsible standars aware developer, we are in the terrible minority. And for all the ignorant developers this default behaviour is exactly what is needed to maintain a stable world wide web.

Don’t worry so much - because those ignorant developers will be permenantly stuck with IE7 it will eventually FORCE them to learn to code properly - because none of them will get ‘the new shiny’ from any new specifications or implementations.

I agree that it’s a pain for those of us smart enough to code properly and look ahead - but I’ll gladly sacrifice a little progressive enhancement (which is about minor graphical touches, not major design issues) if it means creating a stable web, and the higher likely-hood of forcing people to learn properly in future.

# Posted by Matt Wilcox on Tuesday, January 22nd, 2008 at 6:41pm

Brad Dielman

You so eloquently state what I have been trying to say (poorly I may add) since I read Aaron’s article on A List Apart.

All I could say was that this move to target browser versions did not seem right to me. Instead of a step forward, it was a leap back to the bad old days of browser sniffing. At least in my opinion.

Its like Drew said, "Build things properly - then they don’t break." Do we really need to resort to a flawed system like this to compesate for laziness on the part of web developers who do not keep up with industry best practices?

Jason Campbell

I totally agree with you on this, the newest version of a browser should in no uncertain terms demand of whatever content it is presented with to conform to those standards that the browser is capable of handling by default.

If it doesn’t, if that in fact breaks sites that exist currently then good, great, wonderful. This is the best thing that one could hope for, that it will force those responsible for that content to move their site forward, more in line with the standards thereby improving the experience and accessibility for everyone.

You can’t look at the browser as if it were any average piece of software, backwards compatibility shouldn’t be the main concern when you implement new versions, move forward improve and grow. It’s not just about adding features, it’s also about correcting errors and aligning with the accepted standards.

I understand that there must be backwards compatibility, that too much cost is involved for some, too much impact to so many to force acceptance of what is new with no regard to what came before, but if there is to be a crutch let it be for the old content to accept and implement not for the new.

J.

Andrew

Well said. Is there a petition? Where do I sign?

# Posted by Andrew on Tuesday, January 22nd, 2008 at 7:18pm

Robmcm

very well said!

# Posted by Robmcm on Tuesday, January 22nd, 2008 at 7:21pm

Paul Hart

Thank you. This is very helpful to me. This whole situation has been kind of confusing. Even as long as I’ve been in the business, it seems to me that something’s screwed up. It feels like something else must be behind all of this. Something’s fishy.

# Posted by Paul Hart on Tuesday, January 22nd, 2008 at 8:07pm

Dean Edwards

I’m nominally the head of the WaSP/MSTF. I was against version switching from the beginning. When Microsoft say that there was discussion with the WaSP they mean that there was discussion with Aaron. I was opposed to version switching and recommended a change of UA string. Aaron pretty much went out on his own in publishing this article on ALA.

David Mead

If we are going to have to use a tag (and let’s face it we probably are) lets initiate it the same way as conditional comments. If you include the meta tag within the head and your version is lte IE7 then render as if it’s IE7.

The browser should render all other pages as they see them. Warts & all.

I’ve never used DOCTYPE switching as a way around problems and this just smells of pandering to me.

Maybe I’ve got hold of the wrong end of the stick, but that wouldn’t be the first time :-)

# Posted by David Mead on Tuesday, January 22nd, 2008 at 8:37pm

The Doctor What

So wait, MS was upset because customers were confused about web sites looking different. Not because they were broken, but because they changed between IE6 and IE7?

From the ALA article, I assumed that the pages were indeed "broken" not just "different".

Ciao!

Lionel

You are overlooking something: Microsoft has no choice concerning existing web content, they have to assume it is taylored for IE 6 or 7. However, they have some leeway for HTML5 content (new, unusual DOCTYPE) or XHTML content (unusual MIME type). It is quite possible for Microsoft to set IE 8 mode (or whatever will be the current IE version when they will start being supported) as the default in these cases. In fact, Chris Wilson suggested on public-html (when versionning was first discussed) that he would like to do it this way.

If IE is not forced into breaking behavior after html5 support is introduced (and html5 is designed to try to avoid such problems), it would eventually be possible to phase out X-UA-Compatible for new content. Rather than asking for IE=edge (or even IE=8) by default for all pages, which IMHO will not happen, maybe you should ask for the most standard-compliant mode for HTML5 and XHTML pages. Even if this is not all that you would like, it looks much more likely to happen.

# Posted by Lionel on Tuesday, January 22nd, 2008 at 8:47pm

Rob Knight

I had no idea that was the intended behavior. I can’t think of a better way to stifle innovation than to require webpages to opt-in to a more modern rendering engine.

# Posted by Rob Knight on Tuesday, January 22nd, 2008 at 9:05pm

What exactly do you mean when you wrote "If enough of us make our case clearly"? Unfortunately, the tone of most of the contrarian posts to Chris Wilson’s blog, at least, is exemplified by this post from "youcantbeserious":

"This is the absolute worst idea the IE team has had since…the last one. It really would be best if you’d just discontinue IE development entirely. Seriously. Think about it."

Really, that’s not far off. Most of the "commentary" I’ve read on the issues has amounted to trolling.

# Tuesday, January 22nd, 2008 at 10:25pm

Colin Morris

I’m not so sure why it’s wrong. Part of what Chris was saying at the Web Directions South con was that IE can’t "break the web". Muck up pages built to cope with the existing dominant browser. If IE 8 defaulted to IE 8 behaviour, the existing web would break.

By ‘existing web’ I’m mostly talking about banks, government agencies, shops and other areas that people who don’t grok the web go to frequently and frequently the sites don’t grok the web either. With IE 8 defaulting to old mode, then the older sites don’t break. Newer sites built to ACID 2 etc. know about the IE 8 DOCTYPE header and can do something simple about it. Once IE 8 and the other real browsers get a dominant market share, it’s easy enough to fire out an update that turns IE 8 into IE 8 default.

I know there are arguments against supporting bad standards (what standards, yeah) and supporting bad behaviour, but if we’re whisking the table-cloth out from under the web it’s probably best if the vases most people care about are still standing. It should be opt-in, yes, but only once the stuff on the table is likely to remain upright.

Jakub Nesetril

Re: default behaviour - look at it from another point of view:

1) let’s say you write your code today and check it in Firefox2 and 1, Safari3 and 2 and IE8, 7 and 6 - and mark it in the META tag as being verifiably correct in all those browsers. You deploy your website, get paid, customer says "thank you very much" and walks away, saying he’ll do the long-term support himself

2) A year later, IE9 comes out.

3) At the time you wrote your code, you had no idea if IE9 might break something for you. Until you (or whoever maintains the site now) verify your code in IE9 and mark the page as IE9 compliant (in addition to IE8, 7 and 6), IE9 NEEDS to render your page in IE8 mode. If it never gets review for IE9 compatibility, it needs to be rendered in the latest engine known to be compatible.

4) If it doesn’t (and automatically renders in IE9 mode since you haven’t included any version targeting) then you have the whole IE6/IE7 broken web fiasco all over again. Again you have developers churning out pages in blissful ignorance without any explicit contract - and IE (or any other browser for that matter) not knowing if this ignorance was committed in IE8 or IE9 or IE10 ages.

Summary: Without the IE defaulting to IE7, the whole tag is an ill-born concept and can be discarded right away. For the same reason, the inclusion of the "edge" keyword is very risky.

Chris Wilson

Jeremy - any content-type or DTD that is not broadly deployed when we ship can be opted in to best standards support. So HTML5 can be opted in; the XHTML mime type could be, as could any other MIME type IE7 doesn’t recognize.

However, the problem is that we can’t tell the difference between your content (valid HTML with a correct HTML 4.01 DOCTYPE) and that of someone who hacked up their own content to work with IE6/7 when faced with an IE browser, and whose content will break entirely if we correctly implemented standards as specified.

# Posted by Chris Wilson on Wednesday, January 23rd, 2008 at 12:01am

Thom Shannon

It does seem wrong that IE8 will render as IE7, but the more I think about it the more it seems to make sense. If you use an innovative feature not currently supported by IE the chances are you’ll add a workaround for IE, sticking to the edge will cause some odd results.

If the site works well enough in IE7 then what’s wrong with it just staying that way? Why does it need to be rendered in a new engine if it worked in the old one?

I don’t think it’ll stop developers adopting standards, they’ll be features they want to use in the latest engine, like new HTML5 semantics, but they’ll be able to choose when they want to step up to it.

This will also free up MS to make some major changes to fix the engine, they may also make more regular minor releases with rendering upgrades. If other browsers follow suit it could be a great feature.

I wonder how many versions back they’ll support though? And how it’ll effect browser performance running multiple renderers.

# Posted by Thom Shannon on Wednesday, January 23rd, 2008 at 12:17am

Ka-Ping Yee

I am in complete agreement, based on everything i know and have read so far about this proposed feature. "IE=edge" should not be an option; it should be the default behaviour — exactly the same as the default behaviour in every other browser that does not recognize X-UA-Compatible.

# Posted by Ka-Ping Yee on Wednesday, January 23rd, 2008 at 1:17am

Ben Buchanan

I have to agree that the crux of this issue is the default. This system should be a life raft for developers with sites that will actually break, not an imposition for the rest of us who built to standards (then handled IE’s quirks with hacks or conditional comments).

Defaulting to the old version will hold the web back. The default should always be "render according to the W3C standards defined for the doctype". That’s the real solution. I do believe Chris Wilson et al want to produce a fully standards-compliant browser; but I don’t share their optimism that this proposal is good for the web in general.

It’s like spam! It should be OPT-IN, not OPT-OUT.

minimal design

Thank you for clarifying the fact that not all WaSP members were in on this insanity. It makes me feel a little better. I couldn’t agree with you more. Hope it’s not too late… If there’s anything I can do to help, feel free to stop by my site and let me know.

Thanks!

Bradley Wright

I agree 100% with your thoughts on this. I’ve always been coding my sites along the lines of progressive enhancement—that is, to make sites work as well as they can in less-capable user agents and then enhance them for more-capable ones. Making me add an extra HTTP header of IE=edge to achieve what I’ve always previously done, as someone who actually knows the specs and writes correct documents, is madness.

What concerns me the most, however, is the way everyone is talking about this as though it’s written in stone and non-negotiable, and the way WaSP seems to have been completely ambushed (as a whole) on this topic. Microsoft is clearly paying lip service to standards-savvy developers the world over, and WaSP doesn’t seem to have our interests at heart either.

jamie knight

hiya,

Sounds like Microsoft are trying to sideline the industry. All of a sudden i really don’t care about ACID2. Standards are there to be followed, they are making a huge problem for the web.

^licks^

Jamie & Lion

# Posted by jamie knight on Wednesday, January 23rd, 2008 at 12:25pm

AlexM

I don’t agree that this could have been a great feature. How are Opera, Firefox and Safari supposed to implement an IE=7 page? This element makes incompatibilities a pseudo standard and that’s really bad.

# Posted by AlexM on Wednesday, January 23rd, 2008 at 3:05pm

Tom

You know, the more I think about it, the more I believe that making IE8’s new render mode OPT-OUT makes the best sense for all concerned. Obviously, I’d like to not have to have it at all, but I can see why MS feels they need it. The fact that it can be set with an HTTP header rather than having to edit current pages in order to set (or un-set) it would offer a fairly easy way for sites that do not want IE8 to use the new render mode to keep their old, expected behavior. They probably should upgrade anyway, but least if they don’t, it would be on them to choose the mode, rather than anyone who chooses to develop more forward looking webpages.

Would it make sense to start a web petition to try and convince MS to adopt an opt-out policy for IE8? I would be very much behind something like that, because I think some sort of pervasive action should be taken.

# Posted by Tom on Wednesday, January 23rd, 2008 at 6:57pm

Greg K Nicholson

I agree that the default should be to provide the best standards compliance.

I also think that since web developers did update their pages to suit IE7, they won’t mind adding an extra meta element instructing IE8 to act like IE7. And this update would just be adding one determinate line, rather than having to figure out a new set of quirks.

The Penguin

Why not just make IE8 fully standards compliant in the first place?

That way any site (correctly) written to standards wouldn’t care which rendering engine was used.

# Posted by The Penguin on Friday, January 25th, 2008 at 12:25pm

Jamie Strachan

My initial reaction was similar to yours but I’ve since reconsidered. The elegance of DOCTYPE switching was that those developers who didn’t know any better would get their sites demoted to the older (and more flawed) rendering engine. This is the same situation. Those of us who are tuned in to the state of the technology will be able to take advantage of it. Those who aren’t at least won’t be ‘breaking the web’ for the users of their sites because IE will keep them blissfully unaware that anything has changed (even though we’ll know they’ll be forever stuck in 2006).

I think that the end user makes out just fine (which is the most important thing) as long as we keep doing our jobs. Furthermore, adding one meta tag to the repertoire seems pretty easy compared to the time we’ve all spent learning (and unlearning in some cases) the star hack, the underscore hack, the Holly hack, conditional comments, etc…

Barry Bloye

While I can understand Microsoft’s desire for version freezing, and why they think it’s a good idea for developers to opt-in to ‘IE8 mode’, I’m not convinced that the proposed default behaviour will actually solve anything.

Surely, most of the problems that Microsoft are trying to address are with sites created for IE6 and earlier.

Falling back to IE7’s rendering would only benefit those who have developed their sites using IE7’s ‘Standards’ mode, but have still somehow managed to use incorrect CSS and what-have-you. And these are all going to be sites that were either recently created, or at least brought in to line with IE7’s rendering, not the Web ‘legacy’ that this recommendation is supposedly protecting.

IE7 does have its issues, but tightening up the Standards-support is hardly going to have catastrophic effects for any sites that were developed for IE7 at its best behaviour, while sites developed for earlier versions will still reveal their problems under ‘No meta-tag, IE7 mode’, anyway.