The versioning switch's default is correct

Even clinically dead web developers will by now have seen the announcement of IE8's new versioning switch, and many bloggers I read have already reacted—most of them negatively. See the IE page of my linkblog for an overview.

All in all I am in the Yes camp, and in this entry I'd like to offer a few arguments in favour of the current default of the switch. In my opinion, defaulting to IE7 in the absence of a switch is the correct behaviour.

I won't be offering practical arguments, since these are not received too well right now. Instead, I'm hoping to appeal to our collective sense of honour.

Disclosure

Before continuing, a disclosure. I have been aware of the upcoming changes for the past few months and, together with Aaron Gustafson, have advised the IE team on specific issues. As Aaron has already let slip on the WebStandards.org blog, I'm working on a third ALA article that will give detailed, factual information on the working of the switch.

That article isn't yet ready, by the way. I still need some information, and the IE team, ALA, and I feel that it's more important that this article will be complete and correct than that it'll be published quickly. So you'll have to have some more patience.

Essentially, I made the same journey as Eric did. I started out strongly negative. In fact, I originally contacted the IE team because I was concerned about what was back then called "super-standards mode", and I hoped to convince them to drop the idea.

Instead, they convinced me.

When the IE team explained the purpose and working of the switch, I gradually became aware that it is the best possible solution to a knotty problem. Not the ideal solution—certainly not from a standards-aware web developer's point of view—but the best practical one.

I won't talk about practicalities, though. Such arguments are currently out of fashion.

Who will have to change his ways?

The most important solid argument against the versioning switch is that the default behaviour is wrong.

People who want to keep their sites locked in IE7, so the argument runs, should be required to add a <meta> switch. That would allow standards-aware web developers to do nothing in order to retain the benefits of forward compatibility.

Jeremy was the first to raise this point, and he was quickly seconded by a whole host of bloggers. Jeremy wrote:

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!

I interpret Jeremy's post as "If somebody can persuade me that the default behaviour is a good idea, I'll support the switch". Challenge duly taken.

Let's first state the obvious: somebody will have to add a switch. Either standards-aware web developers will have to add it to engage IE8 mode, or unaware developers will have to add it to engage IE7 mode.

Noblesse oblige

Now who's better equipped to understand the switch and all that it entails: the standards-aware web developer who knows his CSS and browser tricks inside-out and follows the news eagerly, or the unaware web developer who by definition is unaware of everything?

We are standards-aware web developers. We like to contrast ourselves to people who don't know what they're doing because we understand our doctypes and floats. We think of our ways as better than those based on tables instead of CSS.

If that's true (and this assumption underlies the entire current discussion), we should also consider the flip side of that superiority.

Noblesse oblige. Since we know more and can do more and better things with web sites, more is expected of us. If our ways are so much better, we should shoulder more responsibilities than those whose ways are wrong. Our shoulders are fit to bear these burdens; theirs aren't.

Being standards-aware web developers means that we take the more difficult, but (so we passionately maintain) more rewarding and more correct road. So let's take it and let's not complain about the extra work.

Our pride requires no less.

Forward compatibility

Besides, so the argument continues, if the switch's default would engage IE7 mode we'd lose the benefits of forward compatibility. This is totally correct.

My take is: so what?

Forward compatibility is not a web standard. It's a theory—a simplified description of reality that helped us choose the right approach for building web sites.

Who exactly promised us eternal forward compatibility? W3C didn't. Browser vendors didn't.

The web developers who created the idea of forward compatibility assumed that it would work forever because that assumption made sense at the time they were working.

Their efforts and ideas are to be applauded, and they certainly helped us along, but when all's said and done forward compatibility has never been more than a theory.

Now it turns out to be a theory that may not describe reality perfectly.

When I was in university I learned that whenever a theory doesn't match reality, the theory should be altered. So it looks as if the theory of forward compatibility will have to be changed.

What's the problem with that? Are we standardistas so intellectually impoverished that we cannot create a new theory of making web sites when we need one?

I beg leave to doubt it. We've got plenty of very smart people on board who will not only be able to come up with an alternative theory, but who will even like the challenge.

So let's search for a new theory. It promises to be fun.

(Web developers can retain forward compatibility by using the edge value, which was inserted exactly for this purpose. For reasons I don't quite understand, suggesting this course of action is like cursing in church at the moment. So be it. The sole avenue of retaining forward compatibility has been closed by majority vote, then.)

So...

So I believe that the onus of implementing the switch should rest on those shoulders best able to bear it: those of us standards-aware web developers. Unaware web developers need all the help they can get; that's why the default favours them.

In addition I believe that we should say goodbye to the theory of forward compatibility instead of requiring reality to match it. It has helped us mightily in the past, but that's no reason to remain attached to it forever.

No, it won't be easy, but nobody ever promised it would.

We signed up for the duration. So let's get on with it.

This is the blog of Peter-Paul Koch, mobile platform strategist, consultant, and trainer. You can also follow him on Twitter.
Atom RSS

I’m speaking at the following conferences:

(Data from Lanyrd)

Categories:

Monthlies:

Comments

Comments are closed.

1 Posted by Oliver on 28 January 2008 | Permalink

I'm disappointed to learn that you support sticking to the status quo: that we developers should be required to pick up the slack for those who cannot or will not raise their game.

While forward compatibility may not a web standard it is not a theory either: It is a desirable best practice, and "breaking the web" is the legacy of years of inactivity on the part of Microsoft. They are to blame for the consequences of starting so very late to comply with standards.

I cannot accept that our community should continue to work harder simply because Internet Explorer has been so appalling for so long that even the attempt to fix things is a kludge.


2 Posted by Sander Aarts on 28 January 2008 | Permalink

I'm very very curious about your article ;-)

Perhaps you can persuade me with it, but for now I just see a 'fix' being proposed that doesn't really fixes anything. It only covers up the problem untill this switch can not be maintained anymore (supporting all rendering modes from IE7 up to the latest is not very likely to be maintainable). The broken pages will still be broken by then. Perhaps some of these pages will have vanished when this happens, but that's just a wild guess.

Take your time to write a good article, but please do it quick ;-)

3 Posted by Isofarro on 28 January 2008 | Permalink

PPK: "Instead, they convinced me."

Convinced you of what:
1.) This is a good idea for Microsoft, or
2.) This is a good idea for web standards developers?

Your statement of: "Not the ideal solution—certainly not from a standards-aware web developer's point of view—but the best practical one." seems to suggest its a good solution for Microsoft, but not for us web standards developers.

4 Posted by ppk on 28 January 2008 | Permalink

Isofarro:

Convinced me that this is the best (or at least, least bad) solution for both Microsoft and web developers.

Web developers want IE8 to support the standards better, and some want IE8 to ram web standards through other people's throats. That's most easy to do by upgrading IE and leaving existing sites in the lurch.

Microsoft wants to serve the existing non-standards-aware Intranet-developers. That's most easy to do by not upgrading IE at all.

Instead, it opted for a conditional upgrade that gives both parties part of what they want. Intranet-developers don't *have* to switch to IE8, while standardistas may, if they so choose.

True, it's not ideal from the web developer's point of view, but neither is it ideal from Microsoft's point of view.

It's a compromise; the best we could hope for.

5 Posted by Isofarro on 28 January 2008 | Permalink

ppk: "It's a compromise; the best we could hope for."

So we are compromising our forwards compatibility, our browser agnosticism, and standards compliant browser vendor's trust. What are Microsoft compromising?

6 Posted by Guy Fraser on 28 January 2008 | Permalink

So how come all the other browsers don't need this switch, eh?

Why is it only MS, who created these problems in the first place, that need us to add this "opt-in to standards" switch?

I'm sorry, but no matter how you skin it, it's evil.

Think of it this way:

There are finite web pages in existence, the majority of which will work in IE8 if it used standards mode by default.

Yet there are an infinite number of web pages that will be developed in the future.

Why are we adding a switch to an infinite number of future web pages (and existing pages) when we could be adding it (easily!) to a much smaller finite number of old pages.

Also, old pages contain old information - why are we holding on to information that's so far past it's "sell by" date that people aren't even going to be reading it or maintaining it?

Please, take your head out of Microsoft's arse and look around you. Think real hard about what this means for everyone else before telling us that Microsoft did a good sales pitch on you and you swallowed their lock-in pill.

7 Posted by Milo on 28 January 2008 | Permalink

I am totally on your side (although I've had a lot of Zeldman's kool-aid recently). If the goal is to move forward without breaking anything, both versioning and the default are needed. That said, my worry is about what this means for other browsers.

If an unaware developer "hacks" something together that looks good in the IE8 rendering engine, then chances are somewhat decent that it looks good in other browsers as well. Instead, those sites will be built to display in IE7, and many future sites will either look bad in other browsers, or those browsers will need to add "IE7 quirks mode".

8 Posted by Jack Sleight on 28 January 2008 | Permalink

I'm slowly coming round to the idea of the default being IE7, but I certainly don't see the need for us to abandon forward compatibility.

The reason we're in this mess is because of IE's past and current flaws, but IE8 is (what I hope to be) a major attempt at fixing those flaws, and bringing it up to the same level as other browsers (who I do not see needing to abandon forward compatibility).

As I've mentioned in the comments on Eric Myers blog, I agree that something is needed for the jump from IE7 to IE8, because the IE8 "super standards mode" is so radically different. However from that point on, we shouldn't need a switch for future versions, as forward compatibility should hopefully be maintained.

If other browser makers can do it surely the IE team can as well.

9 Posted by Rimantas on 28 January 2008 | Permalink

It's a compromise, the best Microsoft could hope for.

10 Posted by David Dorward on 28 January 2008 | Permalink

Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.

I suspect that everyone would be better served if developers who know more about standards educate those who don't rather then doing extra work to compensate for the lack of education.

11 Posted by ppk on 28 January 2008 | Permalink

Isofarro:

"So we are compromising our forwards compatibility, our browser agnosticism, and standards compliant browser vendor's trust. What are Microsoft compromising?"

Microsoft (more correctly, the IE team) is compromising with the forces that don't want to spend money on a browser that already "works" in corporate environments. It's compromising with the people who don't care about web standards and hold the purse-strings.

BTW: as far as I'm concerned we're only compromising on forward compatibility. I'm as browser-agnostic as always, and if anything this episode has given me more trust in Microsoft as a browser vendor instead of less.

12 Posted by patrick h. lauke on 28 January 2008 | Permalink

"I'm as browser-agnostic as always"

but since opera, safari and mozilla have stated that they won't be following the example set by microsoft, using this meta is not being browser-agnostic. it's the principle that's at fault here.

13 Posted by patrick h. lauke on 28 January 2008 | Permalink

in the article, aaron states:

“We could specify the version of the languages we use, such as CSS 2.1 or JavaScript 1.5. Unfortunately, browser vendors often implement only part of a spec and the interpretation of a specification often differs from browser to browser, so any two contemporary browsers may offer completely different renderings of the same CSS or may trigger completely different events from the same form control.”

well, how’s this: what if we were to version the languages, and carry on doing EXACTLY what we’re already doing to accommodate for differences in browsers, i.e. use conditional comments and possibly a tiny amount of hacks/javascript-based sniffing (capability sniffing and/or browser sniffing)?

14 Posted by patrick h. lauke on 28 January 2008 | Permalink

(continued)

personally, my gut feeling here would be that this is more “right” – you’re defining which W3C spec you’re assuming for the page to work, and make slight accommodations where you know for a fact that a specific browser hasn’t implemented it right. it’s specifying the capabilities expected of a browser, rather than the exact browser and version number that the page assumes.

old legacy/intranet sites can stay as they are (without the versioning), and then it can be assumed they’re using the current JS spec and CSS 2.1. that would be the frozen bit: if you don’t version, this is the assumed spec. IE can then do whatever it likes when it comes across those pages…kick in a separate IE7 rendered / JS engine or whatever.

yes, developers would have to modify their code to add versioning, even to their existing sites. but this feels descriptive (similar to doctypes, it’s something you add to your page to explicitly describe what it IS, not what it should do…a subtle, yet fundamental difference in my eyes).

so…somebody explain to me again why this wouldn’t be far more desirable? am i missing something?

15 Posted by ppk on 28 January 2008 | Permalink

>"I'm as browser-agnostic as always"
>
>but since opera, safari and mozilla have stated that they won't be following the example set by microsoft, using this meta is not being browser-agnostic. it's the principle that's at fault here.

Sorry, but I have to disagree. The meta switch is only for IE; definitely. But how will including it hurt the other browsers? I've heard this argument here and there, but I have yet to understand it.

As to principle, it's similar to adding display: -moz-inline-box for Firefox's sake. It's just a browser-specific addition to an otherwise cross-browser page.

16 Posted by ppk on 28 January 2008 | Permalink

Patrick:

>well, how’s this: what if we were to version the languages, and carry on doing EXACTLY what we’re already doing to accommodate for differences in browsers, i.e. use conditional comments and possibly a tiny amount of hacks/javascript-based sniffing (capability sniffing and/or browser sniffing)?

I'm opposed on principle to hacks and browser detects.

Other than that, I don't think this will work. Suppose all browsers suport JavaScript1.7 - there still will be differences.

Besides, what Microsoft wanted was a specific switch for IE only, and I must say I find that more useful than browser-independent (hence untrustworthy) statements that they support this or that version of CSS or JavaScript.

The versioning switch gives us a 100% reliable way to distinguish between IE versions. Your proposal in the end wouldn't, because it would come down to translations. "Oh, if it says it supports JavaScript1.8 it must be IE9."

17 Posted by Milo on 28 January 2008 | Permalink

As I understand it, there are tons of ways this could be done differently which would all be better in the long run.

However, without versioning as MS has "proposed" it, there is no long run. MS simply can't afford to, and won't let themselves, release IE8 if it means *any* of its customers will complain about IE8 breaking their site. That means that without versioning and the IE7-default, there won't be an IE8.

If I have to pick between IE7 forever and IE8 only for people who know what they're doing, I pick the latter.

Some people might have been more agreeable if MS had said "we're going to upgrade our browser but nobody will know how much better it is now unless you guys help us out and put this tag in your standards-compliant sites," but alas.

18 Posted by Kilian Valkhof on 28 January 2008 | Permalink

I am sad that you see this as the practical way. As Guy Fraser said quite well: We have a finite number of sited in the past, but an *infinite* number of sites in the future.

So. Would you rather 'fix' a finitive, and decreasing number of websites, or continue locking yourself in the moment of time for each of the infinite number of sites developed in the future. I challenge you (and anyone) to pick the one you consider most practical in the long run.

Furthermore, I'm amazed that not more people pay attention to Microsoft's reasoning. Microsoft got a lot of complaints that IE7 broke websites. Do you think web standards following developers complained because they had better css support? *no, no no no!* The users of old, outdated (intranet) sites complained. because *their* sites didn't work anymore.

This switch is a legitimate idea, I'll admit as much. However the reason this is implemented is because of the people already complaining to MSFT, and this sole facts should make anyone realise that they are the group best approachable and best told to add a switch to make their site usable in IE8.

19 Posted by BARTdG on 29 January 2008 | Permalink

I think the consequences of a fully standards compliant IE8 will not be terrible. As a Mac user, I hardly ever use IE and there are just a few sites that don't like SF or FF at all. So how bad can it be if they make IE8 behave like SF, FF and OP?

But of course Microsoft are never going to let IE8 "break the web". And although I think they should solve this problem by adding a "Does this site look odd?"-button (to switch IE8 into IE7-mode) I fully agree with PPK that this meta-element is the least bad solution.

I said this before, but feel I have to repeat it:

I will only use the meta-switch, if IE8 is as standards compliant as the other browsers. If it's not, I'll ignore it and wait for IE9 (or IE10, or...). I am not going to invest in yet another sort-of-standards-compliant-but-not-quite- yet-but-better-than-it-used-to-be-mode.

20 Posted by Rimantas on 29 January 2008 | Permalink

BARTdG, I am afraid you will have to wait for a long time. I start to suspect, that this change has nothing to do with "super standards", but rather with a new rendering engine, with new bugs. So basically you will be able to switch between "IE7 bugs mode", and "IE8 new and shiny nevere seen before bugs mode". Looks like IE developers have long forgotten how to develop a browser. Why not just keep IE7 engine for the legacy crap and use gecko/webkit for everything else?
And yes, that should NOT default to IE's engine.
The fact that all this was cooked under NDA blanket does not make it any better :(

21 Posted by Ver Noss on 29 January 2008 | Permalink

You still seem to be dizzy from the NDA. Please reconsider. The inner you must know that it's not right for Microsoft to add a new mode switch now that the old one have made people use web standards.

Will you support them the next time they come up with a new switch to prevent people from using standards?

22 Posted by Richard York on 29 January 2008 | Permalink

I'm not convinced. I still feel this is a terrible idea. Primarily because at the heart of this idea is the proliferation of laziness, bad design, and bad practice. I want standards put first. I don't want to be teaching new web developers about IE7's crappy ways in the future. That this is an issue at all is entirely Microsoft's fault in the first place, and I have no sympathy. Which is not out of blind, conceited hatred, but because we were ignored for five years.

Moreover, I'm even more disgusted that this entire "solution" came about out of secret talks with a handful of select industry experts instead of out in the open with the entire community.

And moreover, Microsoft could also provide installers for the lazy, unaware developers to "fix" their websites with a backward compatibility invoking switch. They can provide Active Directory settings for backward compatibility of specific Intranet sites who surely also exist on networks comprised entirely of Microsoft products. My point being this, just because this solution came out of Microsoft with the support of a couple of well known people doesn't make it the right one.

The only solution I'll support is one that puts standards first and backward compatibility 2nd.

23 Posted by Michiel van der Blonk on 29 January 2008 | Permalink

I see a different scenario possible. MS ships the new IE8 with full forward compatibility mode (edge) as a default, as all standards aware developers expect it.

But, they also deploy a 'crippled' version of IE8 that has all the security features and what not but will render using the IE6 engine.

This way, we (the standardistas) have nothing to worry about, and the unawarez will have to go look for a quick and dirty solution online. It will present itself quickly: upgrade to the new IE8-64bit-Vista-that-does-not-break-your-site-version. Then the only one who has to deal with the burden of past mistakes is... Microsoft. And that's how it should be.

Can someone explain to me if this scenario has already been looked at and why it was thrown out (by MS sure, but can you think of a reason that helps the community for real)?

24 Posted by Erik on 29 January 2008 | Permalink

How will IE8 handle conditional comments with/without the switch? Is a HTML5 doctype the same as "IE=edge"? Will all future versions default to IE7? Will edge always be edge? Will this switch make it impossible to build IE-only sites and intranets? What if it gets added through tools etc just like a proper doctype was, and create the same situation we are in right now in a few years from now? Will there be a third switch?

Maybe because you know more about IE8 than us, it allows you to see this in a positive way, but for most of us it is very difficult.

In a very selfish way I think the meta switch is great - it means I have an advantage over all those crap developers that don't know about web standards, doctypes and meta switches.

But, in a web community way - hoping for a better web for everyone kind of way, I think this is very sad.

25 Posted by Sander Aarts on 29 January 2008 | Permalink

@PPK:
"The meta switch is only for IE; definitely."

That is not how it is presented.
From the A List Apart article (http://alistapart.com/articles/beyonddoctype) that is also referred to by Chris Wilson on IEblog:

"This is exactly what our group decided to recommend for IE8, and we hope to see it implemented in other browsers as well."

...and...

"This syntax could be easily expanded to incorporate other browsers as well:
[meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" /]"

(the square brackets should of course be angle brackets, but I didn't know how to get them in as HTML is not allowed here)

---

"As to principle, it's similar to adding display: -moz-inline-box for Firefox's sake."

I think it's not. the -vendor-prefix is
* part of the specs
* aiming for progressive enhancement and forward compatibility
* is not targeting a static version

26 Posted by Sander Aarts on 29 January 2008 | Permalink

Although I'm not in favour of the currently proposed implementation of the switch, it would already be a lot better if it were only to distinguish between IE7 mode and latest mode (edge). But it seems that's just what MS does not want.

Even though targeting for specific versions, from IE7 and upwards, at first seems to prevent us from introducing new "breaking the web" issues in the future, it will probably do just that. Any version that can be targeted using this switch will have to be supported in all future IE versions, as dropping support for it will break pages that target it.

I see there's need for some sort of switch to compensate for the switch towards standards compliance that IE is finaly making. But the option to fix a page to a certain post-IE7 version seems like the recipe for future problems and is definitely not necessary.

27 Posted by Sander Aarts on 29 January 2008 | Permalink

Possible solutions as I see them (in order of preference):
* Inserting a switch in broken pages instead of valid pages, with a manual switch in IE for broken pages that are not (yet) updated. This would fix the broken part of the web.

* Forking IE, where the old IE6/7 branche is phased out, similar to Netscape > Firefox. This would not fix the broken web, but will stimulate updating to web standards. I'm sure this is not going to happen though.

* ...

* Inserting a switch into valid, compliant pages, only to switch between IE7- and IE8+. From then IE can progress in the same manner as other browsers.

* ...
* ...
* ...

* Inserting a switch into valid, compliant pages, allowing to target a specific version. This is doomed for failure as it will turn IE into bloatware, forcing MS to drop support for some of the targeted versions anyway.

28 Posted by Chris Snyder on 29 January 2008 | Permalink

Seriously, how will IE7 ever _not_ be the default rendering engine? Is MS going to spend 2009 getting all intranet developers to finally upgrade their sites?

I suspect that the number of people who 1) will have broken web pages in IE8 and 2) actually care is pretty slim. Are we talking mission-critical stuff here? And if so, do we really think that the IT shop running it couldn't figure out that X-UA-Compatible would fix the problem?

The fact that the switch can be set using a server header should be enough to ensure that Corporate Webmasters can reliably keep their intrawebs at version IE7 with just a few minutes worth of work.

Please let "edge" be the sane default.

29 Posted by Georg on 29 January 2008 | Permalink

Since there will always be a relatively high number of older versions of IE/win in use at any one time, we'll have to compare and add workarounds for those anyway - no matter which IE/win version is the latest.

Thus, the most practical solution is probably to release new client-work in the "do nothing - IE7 forever" mode for the next few years, while we give IE8 (and later IE9, 10 etc.) a thorough check-up to see if they are worth engaging and if the version targeting is still included or needed.

In a few years time there will hopefully be another doctype available (for HTML5) that'll trigger "edge", and the whole version targeting issue will not be an issue anymore - unless some of those future IE/win versions are so broken when served future HTML versions that we'll have to start all over with new doctype-triggers and version targeting again.

30 Posted by Sander on 29 January 2008 | Permalink

@ppk: I wrote a bit about why this meta switch will hurt other browsers (or at least why they fear it will; widespread use of it definitely making their fear more likely) over at meyerweb: http://meyerweb.com/eric/thoughts/2008/01/23/version-two/#comment-304665
Rijk from Opera chimed in a bit later to say this is exactly what they fear. I've heard similar comments from Mozilla-land. And Hixie follows the same reasoning. (Most of what I tried to explain there came directly from WHATWG discussions about this, back in April when Microsoft first proposed some form of versioning.)

Isofarro asked in comment 3 if this was a good idea for Microsoft, or for web standards developers.
Neither is the right question to ask. What should be asked instead is:
3) Is this a good idea for the web?

Nothing I have seen yet makes me think that question can be answered affirmatively.

31 Posted by Sander on 29 January 2008 | Permalink

Err, s/WHATWG/HTML WG/ in this specific instance, since obviously MS isn't participating in the former.

32 Posted by marty on 29 January 2008 | Permalink

It's forward compatibility vs backward compatibility.

No-one can seriously propose to convert thousands of ancient but working intranet systems to standards. Most don't support Firefox. There are frames, document.all, activex- most sites over 3-4 years old would need to be completely rewritten. Even putting the meta "IE7"-switch in may not be possible in many CMSs.

if MS required standards it would be a Y2K bonanza for web developers, but in the present economy it just won't happen.

33 Posted by patrick h. lauke on 29 January 2008 | Permalink

"Even putting the meta "IE7"-switch in may not be possible in many CMSs."

then they could implement it via HTTP headers...

34 Posted by Jamie on 29 January 2008 | Permalink

Couldn't agree more. I've found all the excited blog posts that emerged after the ALA articles were released pretty depressing. I think that the solution (X-UA-Compatible) itself is elegant, simple and sensible. I also think that sites without it specified should use the engine they were most likely designed for. Finally, I really can't see a problem in asking future developers to specify the engine they wish to use. We already design and test for all the different browsers. Even when Microsoft try their hardest to do something right, they've done it wrong. I wonder how long it will take before Google-bashing is as fashionable!

35 Posted by Lennie on 29 January 2008 | Permalink

However you slice or dice it, I still think it would have been better to make the old-behaviour the opt-in.

Intranet's can easily add a single header to each HTML-page.

And forward-compatibility is not a problem, if there are new standards, there will also be a new doctype.

I suggest we use the edge-variant, to atleast not use a per-version (perversion ?) variant. To make
sure noone relies on some behaviour.

On a different note, is that what all this means is, IE8 does not pass the Acid2-test.

If you point a IE8-browser to the page with the Acid2-test it would render it in IE7-like mode, which
is probably about as bad as IE7 does now.

36 Posted by patrick h. lauke on 29 January 2008 | Permalink

@ppk

"I'm opposed on principle to hacks and browser detects."

but, as all browsers will still have slightly different interpretations, and you'll presumably still need to support "real" IE7 etc, they're a necessary evil, and one that we'll nonetheless have to cater for, regardless.

"Other than that, I don't think this will work. Suppose all browsers suport JavaScript1.7 - there still will be differences."

but again, since only IE will implement the meta/header switch, it won't remove the need to work around things for opera,safari,moz,etc.

37 Posted by Brian LePore on 29 January 2008 | Permalink

@Erik: IE8 defaults to the latest rendering engine if it encounters a DOCTYPE it doesn't know, like HTML5.

@Sander: MS proposed a solution that was not reliant on any of its technologies (e.g. ActiveX) and thus could be implemented by any browser developer freely. That is what the ALA had meant. It is up to Apple/Mozilla/Opera to decide if they wish to support this, which it seems they do not.

Is it just me, or does it seem that one of the more compelling arguments in support of the IE7 default is for non-standista Intranet developers not knowing/wanting to have to update their sites? Why not make the default for connections over an Intranet be IE7, and the default for regular Web connections be the latest version of IE? That seems like a fair compromise to me.

From my experience, most of the non-standards aware developers that are not dealing with Intranets are in Quirks Mode anyways, so this doesn't hurt them in the slightest. The only people it hurts are the standards aware Intranet developers, and they know enough to add the switch.

Also, when did "forward compatibility" ever make it from the hypothesis stage into that of theory?

38 Posted by quentin on 29 January 2008 | Permalink

Have a look at this :
http://dbaron.org/log/2008-01#e20080124a

A better compromise solution for everyone !

You'd really want the whole world's web developper (and the future of the web) to make a compromise for a few non compliant intranets that will be updated in 1 or 2 years ???

39 Posted by ppk on 29 January 2008 | Permalink

Erik:
>How will IE8 handle conditional comments with/without the switch? Is a HTML5 doctype the same as "IE=edge"? [etc.]

All excellent questions that my article will answer. And no, I'm not going to give the answers right now.

Sander:
>I wrote a bit about why this meta switch will hurt other browsers

It says the same as Ian Hickson's post, which I read. However, I first want an actual browser vendor to comment on this. As long as they don't see any problem, I'm going to assume there isn't any.

>Is this a good idea for the web?

As far as I'm concerned, yes. Solving the backward compatibility problem allows Microsoft to focus on enhancing its standards support. I realise that this answer is not popular right now, but it's my answer nonetheless.

Patrick, I'm still thinking about your point about the language versions, and I think it deserves a separate post. I first want to get my arguments in line, though.

40 Posted by Richard York on 29 January 2008 | Permalink

@Erik

Chris Wilson has already said that the HTML5 DOCTYPE will render in "Super Standards Mode" on his blog.

41 Posted by Alex on 29 January 2008 | Permalink

PPK:

One thing is very confusing to me, and maybe you can help explain it. Why are so many groups (including Microsoft, based on the ALA article) so against using the edge value? It seems to me that using the edge value is all that's necessary, according to Microsoft itself, to return to 'forward compatibility'. Why is it discouraged? If us standards-aware developers know how to design with forward-compatibility, why are we being dissuaded? I've heard the argument that if too many people use edge, then Microsoft will break that too. Do you think that would happen?

42 Posted by Tino Zijdel on 29 January 2008 | Permalink

I already blogged about the downsides of version-switching and explicit opt-in last year: http://crisp.tweakblogs.net/blog/122/html5-microsoft-and-the-opt-in-catch.html and haven't changed my mind since. This is very bad for webstandards and the web as a whole.

Call me paranoid but for all I know this may well be a huge anti-competitive move of Microsoft trying to freeze HTML altogether in order to be able to push their own proprietary technologies (such as Silverlight) forward. This is punishing the wrong people and will leave the uneducated uneducated (and thus locked into IE7 mode forever).

I have yet to see prove of the amount of 'damage' that the reverse would cause (opt-out of 'superstandards mode' iso opt-in). If the problem lies mainly with IE-centered intranet apps then why doesn't MS offer a special fabriqued 'Intranet Explorer'?

I have elaborated on my stance in more recent posts, also explaining why using the HTML5 doctype prematurely seems like a bad idea to me.

43 Posted by Sander on 29 January 2008 | Permalink

@ppk: is Rijk's comment - at meyerweb http://meyerweb.com/eric/thoughts/2008/01/23/version-two/#comment-304680 - not enough to count as "an actual browser vendor to comment"?
I don't know what his position is at Opera, but given his use of "we" there, I'd assume he was involved enough for this purpose.
(Plus given Hixie's continuing involvement in Mozilla and awareness of what things are like at Opera, I'd say _his_ comments should count, too.)

Regardless, I'll see if I can get someone else to be more explicit.

44 Posted by Jason on 29 January 2008 | Permalink

I don't agree with the way the switch is being implemented, but I do understand why.

While it is fair to say that the onus *should* be on the lazy developers of intranet sites to update their pages with the new meta tag, the reality is they won't.

In most cases I'm willing to bet that the developers of those intranet sites are long gone and companies have invested thousands of dollars on systems that will be broken in IE8. Since these companies are Microsoft customers, Microsoft has to accommodate them in some fashion.

But is the meta tag really the best way? There are other ways of handling this. What about having settings in the browser that allow the user to determine the mode in which they view the site?

In a corporate environment, the IT team could easily configure IE to view the company intranet in IE7 mode, or IE6 mode while leaving every other site to display using the new super standards mode.

Individual users could be able to set the rendering mode on a site by site or page by page basis, much like how FF handles popups.

While this isn't ideal (some users won't be able to figure out how to change these settings, etc.) it seems a better solution than forcing everyone else to add extraneous markup to their pages.

45 Posted by Sander on 29 January 2008 | Permalink

@ppk: Here's what David Baron said about it back in April:
"A situation like this will make it much harder for other browsers to enter the market. It will mean that, given linear growth in the level of detail specified in standards (especially as standards specify ambiguous cases to improve interoperability), the complexity of implementations will grow quadratically. To implement a Web browser that is capable of browsing the Web, you will have to implement not only what the standards say, but implement reverse-engineered compatibility behavior corresponding to the most commonly used older browser at the time each version was released."
and
"In other words, adding version information will make it harder for competitors to enter the browser market and stay in the browser market."
- http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html

46 Posted by David Baron on 29 January 2008 | Permalink

As an actual browser developer, I've written http://lists.w3.org/Archives/Public/public-html/2007Apr/0279.html and http://dbaron.org/log/2008-01#e20080124a and there are a lot of posts from other people on http://planet.mozilla.org/ .

Also see the WebKit blog at http://webkit.org/blog/155/versioning-compatibility-and-standards/ .

47 Posted by Erik on 30 January 2008 | Permalink

@Brian and Richard

I am aware of that, but what I want to know is, will it continue to trigger "super standards mode" in future IE version just like "IE=edge" will? Or will the meta switch be necessary anyway to keep future versions in standards mode?

Up until now a proper doctype was all we needed to trigger standards mode so if I can keep doing that it would be great.

Looking forward to PPK's next post.

48 Posted by James Burke on 30 January 2008 | Permalink

I understand the need for a new switch. I wish it was not based on product version though.

I want MS to have an out to start developing against standards, but I want the switch to be something that users who use it might actually understand that the browser rendering engine will change over time.

I like the idea of using an URL for the switch, that points to a page that explains the expectations behind the switch, namely, that as new browser versions come out, things might change, but in ways that better fit the standards.

I think of it as more of a "cultural switch" than a product version switch. In that way, I hope that it would not change for every browser release, and that it just meant "IE will match other browsers vendors' gradual improvement on standards".

I wrote up more on this in my blog (a blogger blog, so having to break up the URL for the comment to take):

tagneto dot blogspot dot com

/2008/01/x-web-epoch-instead-of-x-ua-compatible.html

49 Posted by bob on 30 January 2008 | Permalink

What if MS says the heck with all of you; IE8 will only support the standards.

Oh... your intranet doesn't work then use Firefox, Safari, Opera.... oh yeah those browsers won't work either, cause you used IE only hacks.

Fix your crappy coding and STFU.

50 Posted by Richard York on 30 January 2008 | Permalink

@Erik

Chris Wilson has said that the HTML 5 DOCTYPE will trigger "super" standards mode, no meta tag required. He says this in a reply to a comment on his blog.

So, yes, from what Chris Wilson has said, HTML5 DOCTYPE == Edge in IE8.

Personally, my .02 on that news is, while I think that makes the proposed idea a little more palatable, I still feel what's proposed is the wrong solution, which I talk about in greater detail on my own blog.

51 Posted by Sander on 30 January 2008 | Permalink

@ppk: another comment from the Opera side of things, by David Storey: "Microsoft's proposal is bad for the other browser vendors, bad for standards and bad for accessibility. I would consider it to be anti competitive."
and
"I'm still working through all the reasons in my head why this proposal is so bad for the web (and especially competing browser vendors)"
- http://my.opera.com/dstorey/blog/2008/01/26/divide-and-conquer

I've left a comment at his blog asking if he's worked through it all and is willing to comment on specifics.

(Let me know when you're convinced that browser vendors see this as a threat, and I'll stop adding comments whenever I find further evidence of this.) :)

52 Posted by ppk on 31 January 2008 | Permalink

Very quick reaction (little time; I'll get back to this)

David, I saw your mail before; should have thought of it.
The Safari blog entry doesn't mention any problems Safari is going to have because IE will support the switch; only that Safari is unlikely to start supporting it.

But I accept the argument that other browsers will have to emulate several IE modes now. Two points:
1) Can anyone give a specific example of an incorrect IE behaviour that already has been added to other browsers?
2) As far as I can see, other browsers would have to emulate IE8 behaviour anyway, whether it uses versioning switches or not. Then the problem becomes that they'll have to retain their emulations of IE7 (and 6?) bugs, instead of retiring them in a few years. Correct?
I see the basic problem, but I'm still wondering if the situation has become much worse because of the versioning switch.

I'll get back to this problem when I have enough time to write a decent entry.

53 Posted by Tino Zijdel on 31 January 2008 | Permalink

PPK:

@1) quirksmode? And besides that there are probably lots of examples. Having to implement IE propriety technologies such as document.all could also count as an example. I also know that HTML5 will redefine rendering behaviour wrt P and TABLE to match IE's current non-standard behaviour. Fact is that browservendors already have to take IE behaviour into account with everything they do, with this new switch they have to take into account every behaviour of every IE version which makes it much harder to compete in the browsermarket.

@2) if IE8 is as standards-compliant as every other browser what's there to take into account? Other browsers also don't mimic every single quirk of IE6 or IE7 (there are some exceptions targetted at 'almost compliant mode'), but if people continue to cather to these versions of IE, something that is likely to become more widespread when IE7 rendermode will become the default, they may be forced to.

54 Posted by James Bennett on 1 February 2008 | Permalink

Chris Wilson has stated that HTML 5 documents will not need to use X-UA-Compatible in order to trigger IE 8's standards mode. But if authors of HTML 5 documents follow that advice, the next version of IE after 8 will likely "break the Web" for those documents (since HTML 5 will still be in development when IE 8 lands, and since the initial implementation will almost certainly be incomplete and buggy to a greater or lesser extent).

Thus, if we follow Microsoft's own advice, we will find that Microsoft's solution will not solve the problem Microsoft claims to be working on.

Meanwhile, IE already supports declarations of version compatibility for (parts of) documents, via conditional comments. If this existing mechanism is not used widely enough to be effective, or is used improperly, it is unlikely that the introduction of a new mechanism will remedy the problem.

Which means that even in the general case it is unlikely that X-UA-Compatible will solve the compatibility problem.

So why do you support it?

55 Posted by James Ojaste on 1 February 2008 | Permalink

First off, we're talking about IE's rendering model here - the presentation layer. Why are we dirtying up our metadata with presentation details instead of using a CSS property?

Something such as "-ie-rendering-mode: ie7;" in a top-level selector would be safely ignored by other browsers and accomplish all the same goals.

Finally, if MS makes the IE7 rendering model the default, then amateurs and developers who've gotten into the IE-only habit are going to continue creating the same old incompatible sites. By making a more correct implementation of the standards the default, new sites (created by anybody) will be cleaner and more compatible. Isn't that the goal of a standard?

56 Posted by Chris Hester on 5 February 2008 | Permalink

ppk: "I believe that we should say goodbye to the theory of forward compatibility"

Maybe one day when a better solution than HTML has arrived. Until then, I think it is insane to drop forward compatibility. And why? Because Microsoft wants it? Firefox et al have no problems with forward compatibility, as far as I can see. Surely current standards are well enough designed to last for many more years, including things like HTML5.

Brian LePore (comment 37): "Why not make the default for connections over an Intranet be IE7?"

Which would please Microsoft no end! Create IE-only intranets? No thanks!

The browser wars may be back if this proposal goes ahead. If so, do battle with words. Let Microsoft know we are NOT happy with this idea, which may well stagnate large parts of the web, locked into IE-only sites designed for out-of-date browser versions.

I've made a range of t-shirt designs suitable for the oncoming battle. (See link below.) Let's all join forces and combat this growing threat. Don't let Microsoft control the web and hold back standards!

http://www.flickr.com/photos/christopherhester/sets/72157603847933333/

57 Posted by Hallvord R. M. Steen on 6 February 2008 | Permalink

I think it's too optimistic by far to assume only IE will have to support multiple rendering modes if X-UA-Compatible sees widespread usage on the web. My take:
http://my.opera.com/hallvors/blog/2008/02/06/x-ua-incompatible

58 Posted by Greg Blajian on 8 February 2008 | Permalink

OK, I am confused, we are supposed to see this as a good thing, or at least the lesser of all evils? I am by no means a "super" standards developer but this argument begs the question as to why IE7's default was not to render exactly like IE6, and IE6's default to render like IE5 and so forth. How does IE7 become the default rendering from the start and IE8 NOT become the default rendering by default when it is released? When IE7 came out I had to change my site to display correctly in it, granted, I didn't have to make too many modifications since I have a doctype declaration and was already "mostly" standards compliant, IE7 brought us a little closer than IE6, so I fail to see how IE8 bringing us even closer is a problem; especially, when CSS3 will probably be released before IE9 comes out which will mean IE8 will no longer be standards compliant anyway. What is wrong with leaving the quirks mode that is triggered by having no doctype declaration for IE8 for those who don't know or want to learn standards and using the doctype declaration to invoke standards based rendering the same as it is in IE7 and IE6? At first, I didn't think the metadata tag was a bad idea but the more I think about it the less ideal it seems.

59 Posted by Robby on 10 February 2008 | Permalink

This argument is flawed in so many ways. Sadly it could be remedied in one swoop.

IE as it stands should be resorted to historical mode. One that provides the html/web controls for the application developers who use it on windows, and for intranets who largely use it to develop. It should push and carry just security updates (and whatever else they want, providing it allows them to do what they attend to do with this hack - add features without breaking expected.

The next browser coming from Microsoft shouldn't have anything IE related in the query string, shouldn't be considered an update to IE7 and should be considered a wholly new browser to developers.

Then we can develop for the future on a box model that is accurate, rely on less hacks and start working forward in a more designed fashion.

All this does is excuse them continually for what they've done, and send even more bytes (along with javascript and css hacks) down the pipe to cater for them.

Yes they have applications and features they'd rather not break. Don't. Give us a new query string to start coding against.

As a community we worked through IE7, Safari and Firefox. Updated Opera and frankly this is the most sound upgrade path IMO.

60 Posted by Barrett Dent on 12 February 2008 | Permalink

Perhaps the root of the problem here is that Microsoft continues to develop a flawed product.

Would there be less negative reaction if Microsoft announced an entirely new browser with with a new name to distinguish it very clearly from what came before? A new browser with a fresh start, developed with an emphasis on standards compliance and no thought to backwards compatibility with IE.

Then users installing this new browser and developers would not expect this new browser to support IE's horrible previous flaws. Nor would they expect their sites to remain usable eons into the future. Any reasonably important content would get updated out of necessity. We'd also be rid of a dreadful pain in the butt (old versions of IE in all their horrible standards-killing glory.)

61 Posted by John Arthur on 15 February 2008 | Permalink

Here's where I see the ultimate, underlying issue: we aren't talking about 10 years from now. We ask about it, but we don't talk about it.

Microsoft needs to lay out their plans for version tracking in 2018. Everyone's asking if HTML5 is going to render in "super-standards mode" (*shudder*), but I'm adding "... in 2018".

Hixie throws the argument that if we all use edge, edge will default to IE8 (or whatever version is out when everyone starts using edge). Can we get a FIRM confirmation that version tracking will only apply to popular Doctypes ON OR BEFORE (DATE), and that edge will ALWAYS be edge?

Someone answer these questions (I'll need to you to show your work, if you will), and I think we'll see if version tracking is an elegant solution, or an even more grotesque version of the Doctype switch (hack).

And honestly, if you can say 2058 instead of 2018, even better.

JA

PS -> I know none of us know what the Web will be like in 5 years, let alone 10-50, but the concept applies in theory, and we need to think in this sort of long view if we want to actually fix these sorts of problems. So it's purposely impractical, but it's necessarily so.

62 Posted by Cyril APAN on 24 February 2008 | Permalink

I think that the versioning mechanism is pretty flawed. We already got conditional comments and doctype, why add a new "feature" ? It will complicate vendors task and maintaining versioning for all future versions of IE will be pretty cumbersome, knowing that we'll got new versions of the HTML and whatever XML standards (XSL, SVG, etc).
I feel that what's wrong is about the fact that any Windows PC should have a unique version of installed IE. Why shouldn't we keep a "Classic IE" for the sake of old websites that would fall in oblivion not so far from now and "Next IE" for those new websites that should keep track of the standards ?

It's better for Microsoft to release a brand new version of IE that really sticks with the standards, to gradually end with the chaos for newer websites - the greatest power of Microsoft has always been to force THEIR standards after all - and then keep a classic version or an emulation mode of IE7 for those websites which should disappear quickly.