1 Posted by Eddie Welker on 22 January 2008 | Permalink

Well said. Just remember that people are seeing this for the first time, and as you said, will have a heated reaction. Things said in the heat of the moment aren't always thought out. Only the truly uninformed will actually consider this meta proposal a browser detect.

2 Posted by Eric Meyer on 22 January 2008 | Permalink

Thanks, PPK. I tried to make the same point in my ALA piece, but I don't think it can be said enough-- because as you say, this will be a complex enough topic without fallacies clouding the tank.

3 Posted by ppk on 22 January 2008 | Permalink

Eric, you did touch on this problem, and I wanted to link to it but forgot. Link now added.

4 Posted by Drew McLellan on 22 January 2008 | Permalink

"There's a second difference: the versioning switch is a contract."

You're right - Microsoft is promising that IE will continue to be capable of rendering a page the same way for ever.

Unfortunately, I don't believe that's a promise they'll be able to keep. At present they can't even get TWO versions of IE running side by side.

The other issue is for JavaScript developers writing library code or widgets or other code that gets run in someone else's pages. If I write a script today, I have to be sure it works well in IE6 and IE7. That often means a few workarounds and a bit of code branching here and there. I don't have to code for IE5's bugs because largely that's not used. However, this contract from Microsoft also imposes on JavaScript developers that they have to keep supporting all past versions of IE, in case that rendering mode is being used.

Not only does development become very expensive, code will become extremely bloated with all those exceptions and conditions to work around. Therefore Microsoft with be under more pressure not to change too much between versions than they are currently.

5 Posted by ppk on 22 January 2008 | Permalink

Drew, you could of course be correct.

Right now I'm assuming that Microsoft will make sure that IE8 without the switch will work exactly the same as IE7 does now. Without that, the entire switch does not make sense.

What we really ought to do is compare IE5.5 and IE6 Quirks Mode. The latter is supposed to be the same as the former, and a comparison offers actual facts about Microsoft's ability to handle backward compatibility (or not).

(To be fair, back then Microsoft never actually promised that IE5.5-optimised sites without doctypes would render the same in IE6 Quirks Mode).

Anyone in for a comparison? (Facts please, no opinions.)

6 Posted by David Storey on 22 January 2008 | Permalink

I've got further thoughts to this proposal coming, which I won't share now.

However, this contract is impossible to keep. Just take the simple case of a security issue. This *must* be fixed, but effects rendering or how Javascript works (and this is not uncommon). This breaks the contract as the version of the browser that is patched will act differently, no matter what the contract says it should do.

Imagine the extra QA resources that will be needed too . Maybe MS can afford them, but other...? (and remember this closed committee of people propose that other browsers implement this *solution*). The proposal is naive at best.

7 Posted by harley on 22 January 2008 | Permalink

Personally, I have my doubts that this is the best solution. However, Mircosoft has a huge business case here. There are literally thousands of webpages by large corporations that are written in the old, 'flawed,' 'non-standard' way. I think, if nothing else, Microsoft should be applauded for going out on a limb by asking the Web Standards team for help. I think Microsoft could easily launch another vendor war. And they'd probably have a good chance of 'winning' the larger part of the market.

Right now, I don't write any webpages that require a historical backlog. So my main concern is, will this new switch require more work from developers who have always been targetting forward-compatibility?

And, I think the 'edge' keyword is stupid, for all the reasons that Eric stated.

8 Posted by pauldwaite on 22 January 2008 | Permalink

> these browsers are not programmed to recognise the meta tag

Pedant’s corner, but perhaps “this meta tag” would be more accurate. Browsers recognise meta tags in general.

9 Posted by Felipe on 22 January 2008 | Permalink

This switch isn't a browser sniffing, right.

But I wonder:
What will IE8 do *by default* when served with IE=9 or IE=11 pages that would render perfectly in IE8 ? Will it print the same thing as Flash: "Oh you don't have Flash 9 plug-in? Ciao!" for a simple animation that doesn't use at all the functions implemented between Flash8 and 9 plugins. Or opening a Word 2007 document with Word97 or 2k, etc

10 Posted by Felipe on 22 January 2008 | Permalink

IE8 will be sooo perfect that I guess some MS-fans won't care about indicating anything else (like "we only have IE8 in our intranet, same for our clients").
What will have to decide concurrent browsers with a webpage proudly telling them "IE=8" and nothing else, no FF or Safari indication?

A new browser will need not only to be powered by a standard compliant rendering engine but will also need IE rendering engine. Every single one of them!
So Mozilla will have to re-implement, in a few years, IE bugs _again_ in their code for retro-compatibility with IE8, 9, ... like they had to do in ~2002. Oh irony!
This switch is due to IE6 bugs, lacks, etc and still the one who benefits from it is MSFT so will they help every existing and future browser maker into implementing retro-compatibility with their old browsers (old from a 2014 point of view) ? I guess no. Will it need the European Union to fine them a few billions of Euros for locking other browser makers ?
Thus, it'll be harder and harder for new players. Quite nice for the already established ones.

Cost for MSFT: nil (every new page will implement at least "IE=n")
Cost for others: huge!

11 Posted by Alex on 22 January 2008 | Permalink

If MS wants to add a feature to IE8, that's their business to do so. However, their mantra of 'don't break the web' is only a half-truth, because they're breaking many current websites' vision of automatically becoming better/cleaner as IE progresses. I know that all someone has to do is add a meta tag with 'edge' in order to return to forward-compatibility design, but it's like good web designers are being punished with this extra line of code for their forward thinking, and designers who just want their page the same forever without improving over time are being rewarded by not having to put the in the 'Microsoft Meta Mark of Shame'.

I guess we'll just have to learn to put that line of code in and get over it. Nonetheless, here's hoping none of the other browsers decide to do this also, especially because they don't need it at all.

12 Posted by Waylan Limberg on 22 January 2008 | Permalink

"There's a second difference: the versioning switch is a contract. The IE team tells people what will happen if they insert the tag in their pages, and it's up to individual web developers to decide whether they want to use this contract or not."

Not exactly. Without the tag, the default behavior is the same as if the tag was set to IE7. In other words, Microsoft is automatically entering me into this "contract" without my explicit permission. This is BAD! I tried to express this in response to Eric's article, but Jeremy Keith does much better here: http://adactio.com/journal/1402/

13 Posted by John Faulds on 22 January 2008 | Permalink

"In all other browsers it does nothing, since these browsers are not programmed to recognise the tag."

Maybe I read the ALA article wrong, but weren't they suggesting that other browsers could make use of this meta tag too? Or is a it case of they can, but none have suggested that they will?

14 Posted by David Owens on 22 January 2008 | Permalink

@felipe: This is a misunderstanding that I have seen in the comments of a couple of websites now.

Other browsers will not need to ship with an IE rendering engine.

If an author has specified IE=8 (for example), Firefox will still use the rendering engine shipped in that browser. It will render as Firefox, not IE 8.

This would only not be the case if other vendors implement this meta element for their own browser versions. If they were to support it, then their browser would use the version of their engine which is specified, for example, FF=2 or Safari=3. They still wouldn't need to render as IE does.

As their historically better standards support has meant they don't run the same risk of "breaking the web", lets hope that modern, standards compliant browsers can continue not to need version support and that this new element can be ignored by them in the same way that conditional comments are today.

15 Posted by Jeena Paradies on 23 January 2008 | Permalink

So why did Opera implemented document.all and "Internet Explorer" as as default User Agent? Does really somone belive that this will not happen with this meta-tag?

16 Posted by David Storey on 23 January 2008 | Permalink

jeena: Same reason why Mozilla implemented document.all and Safari says it is Gecko. They were needed for compatibility reasons. Sites test for IE or Netscape, and sites use document.all.

There are too many reasons to mention why Opera wont support this, and I'm sure many of the reasons will be similar for Mozilla, and Apple to some extent.

17 Posted by Sander Aarts on 23 January 2008 | Permalink

As we all know IE7 can not be installed on anything but Windows XP or Vista. I'm not sure about IE8, but I can imagine that it will only be available for Vista (does anyone know?).
Anyway, not all users can, or will, update their browser as soon as a new version hits the shelves. This means that we will probably be meta tagging IE6 or 7 as target engine for a long time after IE8 has come out. And as progressive enhancement will not work when a target engine is declared the target audiences for these enhancements will decrease dramatically. This will make it far less interesting for clients and developers to add such enhancements. Therefor adoption of new front-end development/browser features will take much longer, slowing down the entire development in this erea.

I'd say break the damn 'Trident web' for once and for all and be over with it.

18 Posted by Peter Siewert on 23 January 2008 | Permalink

I think this might be related to Opera Anti-trust complaint:
http://www.quirksmode.org/blog/archives/2008/01/operas_antitrus_1.html

IMHO, Opera's complaint isn't that IE is not following standards; their complaint is with this new IE8 feature. Microsoft is taking the stance that they COULD render a page in the most standard compliant way but they refuse to do so for currently developed pages.

This is a case where IE is cheating when it is running into the problem that other browser developers have had for years. Pages written for IE with IE's bugs render impropperly on browsers that dont have IE's bugs. The IE development team's mantra of "Dont break the web" should be clarified; it acutally is "Dont fix the web". They had an opprotunity to make a browser that renders today's pages in a standard compliant way. This would cause rendering problems in IE8, which would mean that the web site would actually fix their pages. This would not only be good for IE8 users, but also users of alternative browsers that actually care about rendering to web standards instead of rendering to whatever the largest browser says the page should look like.

19 Posted by Blaise Kal on 23 January 2008 | Permalink

IE=edge is "strongly discouraged". (source: Gustafson's ALA article)

To me, it says a lot about bugs, bug testing, bug fixing and Microsoft's interpretation of web standards.

20 Posted by GreLI on 23 January 2008 | Permalink

Microsoft got trapped in their own browser popularity. Professional developers makes standart-compliant pages and then adopts it to IE (Microsoft mention this in their blog).

But there are many bad coders that do pages only for IE (most notably 6) and don't care about standarts and other browsers. But why then any other people must care about this? It's a problem of bad coders but not anyone else.

21 Posted by voracity on 23 January 2008 | Permalink

Just trying to think through this with imaginary cases.

Pretend I have a page that I've tested against Fx1 and IE6, and I specify IE=6;FF=1. The page contains fixed position elements, which IE6 treats as ordinary block elements. IE7 won't pick up those fixed position elements because it will render as IE6 does. So I have to update the page to tell it to render as IE7, which means I'll have to fix everything in it to work with IE6/IE7, so I'm back to doing what I have to do now anyway.

Suppose instead I'm pixel-perfect happy with IE6 and Fx1 renderings and I don't ever want to touch the code again. The upside is that users can upgrade and I don't have to worry about breakage . . . in IE and Fx.

Suppose that Firefox has 98% market share and web developers have become lazy. I specify FF=8, and then code my page for that browser only. There are always major quirks in a browser, so if IE12 wants to try reclaiming market share, they will have to create a FF=8 quirks mode. Firefox gets a free ride. In fact, Firefox can make a valuable promise (contract) that others can't *just* because they're not Firefox.

The danger here is positively correlated with web developer laziness. So, how many web developers are lazy? Me, for one...

22 Posted by Sander Aarts on 23 January 2008 | Permalink

As posted on A List Apart as well:

Very interesting article about this subject: End of line Internet Explorer by Mike Davies (http://www.isolani.co.uk/blog/standards/EndOfLineInternetExplorer).

He compares the current position of IE with that of Netscape 5 and suggests that MS should start all over (in the Netscape case this resultet of course in the development of Firefox).
Instead of putting the name IE with the garbage. It might enough to have the User Agent verification string completely altered to such extend that current browser sniffers wont identify it as IE (did I read that here or somewhere else?). This would leave 2 variations of IE:

* IE Classic versions up to IE7, maintained for a number of years for backward compatibility

* IE Superdooper New and Improved – significantly better IE8 and onwards, with similar level of web standards support as Fx, Sf and Op

...

23 Posted by Sander Aarts on 23 January 2008 | Permalink

...

This would mean:

* no pollution of web development and code with yet another ‘fix’
* MS would finally prove that they really want to support web standards
* IE-only developers will know for sure that have to update their skills
* Organisations using applications that rely on proprietary features in the current IE versions will have enough time to update these to ones that rely on open standards
* IE will not become bloatware because of all the old engines they will have to keep supporting
* ‘progressive enhancement’ will not become an endangered species
* MS will not be painfully remembered till the end of time of their past mistakes in browser development and front-end developers might even start to like MS and even IE again

pease brothers and sisters ;-)

—sorry for the bad writing—

24 Posted by Dinoboff on 23 January 2008 | Permalink

@ GreLI:

Remember that IE7 didn't break pages written in quirk mode. Most of the problems were on pages using standards and fixes for IE6. Some fixes for IE6 were inappropriate for IE7 or the hack they were using wasn't working any more for IE7. I don't think this tag is bad for standards.

25 Posted by Sander Aarts on 24 January 2008 | Permalink

@PPK
After about a day and a half... what's your opinion on this switch?

In your "Elsewhere..." blog I read that you didn't agree with the words used by Mark Davies, refering to ghettos and stuff. This reference is indeed a bit harsh, but the default IE7 mode bears a "guilty untill proven" concept.
I liked his comparison with Netscape at the time that thay had to break with their 'evil' past.

In my previous post I stated that MS should fork a new IE that is not bound to impossible backward compatibility. The old IE could then be phased out. Of course this would still break the web by that time.

Rethinking about it I guess it would be better to set the default mode to the current version, as many seem to prefer, and include only one IE classic render mode (IE7) in future IEs. The fixing meta tag should only be inserted into broken pages and these fixed pages will never be a problem again, as they are now *fixed*. For pages that will not be updated with the fix, as not all will, users could manually switch between classic en superdooper mode.

The problem with the proposed behaviour is that it doesn't fix the web, which was already broken a long time ago. It only assures we will not be bothered by it too much this time.

26 Posted by Christopher Boomer on 24 January 2008 | Permalink

If this a contract between the developer and the browser meaning 'tested on' then this switch is a very good idea which will help both site developers and development tool writers.

It allows the browser a chance to decide the best rendering engine to use from those available to it. (For instance, Opera 11 could detect whether IE mode or standards mode was more appropriate, if it was not specifically listed in the tag.)

It also gives the developer time to test and make changes to live sites, marking them appropriately as tested and working when new browsers arrive.

I might suggest that the default rendering for IE8+HTML4 might be better as IE6, since it still has the majority share of users and (un)designed pages.

There is sufficient time to include IE=7 on all sites which have been tested for it. Most of us have updated some but not all sites. IE6 default would reduce the need to bother for truly archived sites.

Over time this will lead to either browser bloat or progressive degredation of unmaintained sites (or, heaven forbid, optional components for 'library viewing').

Curiously, I haven't seen any syntax for 'IE=6,7,8;FF=2,3;', which concerns me. But I haven't read the actual spec, so that might not be a problem.

27 Posted by patrick h. lauke on 24 January 2008 | Permalink

"I might suggest that the default rendering for IE8+HTML4 might be better as IE6"

So, not only freezing the current rendering, but actual regression to previous renderer? crikey...

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

here's a crazy thought, but...what would be wrong with spec versioning (i.e. specifying which css or js spec is being used), coupled with continued use of conditional comments (which we'd still need anyway if still having to support "real" IE6 etc) and a tiny amount of browser sniffing? to me, that feels more fundamentally...like capability switching ("this site uses CSS 2.1") and our tried and tested accommodations, rather than specifying which browser's behaviour should be emulated.

IE could then treat old legacy/intranet sites which don't version css/js in its IE7/compatibility mode. yes, standards-aware developers would still need to modify their markup to add the versioning, but as i said it feels more right to say which W3C spec you're coding against, rather than which browser you're coding against. thoughts?

29 Posted by Christopher Boomer on 25 January 2008 | Permalink

"more right to say which W3C spec you're coding against"

In principle of course this is spot on. Browsers should release rendering engines which meet specifications and state clearly which those are. We'd all like that ideally. That's what the DOCTYPE was supposed to offer.

However, 'tested against' is the information offered by this meta-tag, as I understand it, which provides a contract between the developer and the user based on the reality.

My suggestion of freeze at IE6 is based on my belief that IE7 is not 'better enough' and on the volume of stuff that will already be broken by it. IE6 rendering is so endemic that we'll be stuck with it for years anyway, while IE7 is a stopgap release.

If IE8 doesn't come out until 2012, I will of course be wrong on this.

30 Posted by John B on 27 January 2008 | Permalink

This solution seems like a good temporary fix while IE "fixes" their software. I wonder if in 10 years when IE has matured into a standards compatible browser (and IE7 and below have faded away), will it even be an issue anymore?

31 Posted by Jonathan Swift on 27 January 2008 | Permalink

Resolution of the problem by adopting a versioning switch is surely not the perfect one, but it should be sufficient for now, and help the browser to deal with proper rendering issues. I agree that clear contracts proposed by Microsoft cause less chaos, but I still would like to see a better solution proposed in future. Nonetheless it is sad but true fact, that many problems arise from ignorance and stupidity of web designers themselves.

32 Posted by andrea creviola on 2 February 2008 | Permalink

As always all the problems with IE arise form Microsoft's reluctance to fully adopt standards in their new browser, so the suggested solution will only solve the problem temporarily. I do hope that in future MS will finally a truly standards compliant version of their browser. Then such problems will simply cease to exist.

33 Posted by Howard Davies on 2 February 2008 | Permalink

Be it a good solution or not I really hope that other browser vendors won't follow Microsoft's strategy. Nonetheless, the common myth of sites breaking in IE is simply not true. My sites didn't break and I've heard from noone who experienced such problem.

34 Posted by Hag Smiley on 10 February 2008 | Permalink

It's true, the versioning switch does not have any of the negative effects of a browser detect. It has a conglomerate of other problems, though. Instead of being able to target a given set of W3C Specifications, web authors are now supposed to target a given version of a rendering engine instead. Who in their right minds can think that this is a good idea?

If you really want to target Internet Explorer 6 or whatever version of Internet Explorer's rendering bugs, then that should be your choice and you should make that explicit. The rest of the world trying to code their web sites against W3C specifications should not have to bother with this nonsense, especially considering that they aren't the ones targetting a rendering enine.

The switch is okay, it's just the inverse of what it should have been.