On this page:
So Microsoft announced a way to support standards without “breaking the web.”
The challenge they had was to find a way to “enable (and encourage) interoperable web development, but don’t force IE to break pages that work properly in IE today.”
They eventually settled for a <meta>-based “opt-in to the browser version I tested with” strategy.
What this means is that if you as a web developer want IE 8 to render according to their best implementation of standards then you opt in by adding a particular meta element into your HTML (or send down a similar HTTP header in the response). This is explained in an article in A List Apart.
In other words, for web developers trying to do the right thing they must pay a small “don’t-break-IE-web tax!”
Many prominent web developers and designers have been highly critical of this. But, ironically, will this actually be a positive thing in the long run?
Don’t break the Best-viewed-in-IE web
The IE team described their attempt as a “don’t break the web” approach. Judging by many reactions, it feels they are actually breaking the principles of web development.
And, in their own words they don’t want to “force IE to break pages that work properly in IE today.” In effect they are asking web standards developers to help them out so they don’t have to go and fix all their problems resulting from the IE-driven web which has slowed down web development and contributed to this current problem. (That is probably a bit harsh, as I can certainly understand Microsoft would be unable to fix all the issues in the various places where IE is used! More on that below.)
The lead of the IE team, Chris Wilson, seems to admit this meta switch is a hack but given a difficult situation for Microsoft, trying to support both standards and non-standards developers, this might be the best way to go about it.
So other browser vendors were encouraged to adopt this idea too. However, the guys working on WebKit (the rendering engine behind Safari) felt that,
We don’t see a great need to implement version targeting in Safari. We think maintaining multiple versions of the engine would have many downsides for us and little upside. The IE team is, of course, under different constraints and free to make their own choices.
— Maciej Stachowiak, Versioning, Compatibility and Standards, January 22nd, 2008
having this be portrayed as a general-purpose solution for all browsers, when it’s really just a solution to Internet Explorer’s situation. That’s not necessarily a bad thing. I completely commiserate with [IE’s] situation and don’t envy it at all. It may very well be that this new meta tag addition is the only viable solution – and that’s fine. However showing it as something that is a universal issue to all browsers is definitely not the case.
— John Resig, Meta Madness, January 22nd, 2008
Resig also made an important point about how this decision was arrived at:
On a whole, I really wish that this process had been done more in the open than it was. I doubt that as many issues, that we’re seeing now, would’ve arrived. I absolutely don’t envy Internet Explorer’s situation in the matter so, for the sake of the web, let’s hope they come up with an acceptable solution.
— John Resig, Meta Madness, January 22nd, 2008
Ian Hixie, lead member of the WHATWG (the guys that started defining HTML5), and Google employee, was concerned that browsers would have to implement it, like it or not:
If Web authors actually use this feature, and if IE doesn’t keep losing market share, then eventually this will cause serious problems for IE’s competitors — instead of just having to contend with reverse-engineering IE’s quirks mode and making the specs compatible with IE’s standards mode, the other browser vendors are going to have to reverse engineer every major IE browser version, and end up implementing these same bug modes themselves. It might actually be quite an effective way of dramatically increasing the costs of entering or competing in the browser market. (This is what we call “anti-competitive”, or “evil”.)
It will also increase the complexity of authoring by an order of magnitude. Big sites will become locked in to particular IE version numbers, unable to upgrade their content for fear of it breaking. Imagine in 18 years — only twice the current lifetime of the Web! — designers will not have to learn just HTML, they’ll have to learn 4, 5, maybe 10 different versions of HTML, DOM, CSS, and JS, just to be able to maintain the various different pages that people have written, as they move from job to job.
— Ian Hixie, Mistakes, Sadness, Regret, January 23, 2008
Chris Heilmann, a lead web developer at Yahoo suggests that maybe now is the time to try and mend the broken web; a large number of sites are now created by CMSs and now might be the time to explain, help, and contribute to fixes. “As most are built with frameworks and CMS and one of the main selling points of these was that the outcome can be easily changed in the future, how about proving that now?” A garganutan task it would seem!
(Heilmann also posted a link to this hilarious explanation of how this meta-switch problem has come about.)
Microsoft is in a difficult situation
Resig noted above Microsoft’s situation is not something to take lightly.
The following is perhaps one of the best articles I have read trying to explain Microsoft’s predicament. It is not by a Microsoft employee, but a lead web developer at Yahoo! (and way before the Microsoft buy-out bid!!). Here is a lengthy quote:
[Don’t just consider webservers,] but … other forms of distributing HTML content. How easy is it going to be to configure a webserver, or add a meta tag to HTML documentation on CD? It’s not just a case of editing the HTML and reburning to the CD – what about making sure everyone who has the old CD now has the new one?
Compiled HTML is another source of grief – every chm ebook ever published relies on an IE renderer library to display its content. That content is authored and then distributed to many people. Again, the HTML editing is simple, but the actual redistribution of the non-broken version is a massive problem.
Consider also the number of Windows applications that use the Internet Explorer rendering engine as a component of the application. All the content and logic for those applications would need to be updated, and the application would need to be re-shipped to all the users of that application.
The point here is that web’s solution is remarkably simple, it’s a case of fixing the problem in one place.
Sure, redistribution [for the non-web server-based products that use IE] is just a link to a website to download an update. But every software product, every ebook title, every software documentation would need that redistribution. It’s not a couple of web pages any more, it’s the entire Windows platform, the operating system and all applications (including third party software) that would need updating.
This points to a grievous mistake on Microsoft’s part: integrating the browser (well, the rendering engine) as part of the operating system.
A change in the rendering affects not only web pages, but local documentation, software applications, even so far as the file-system browser Windows Exploring. They all use the Internet Explorer renderer. The moment that renderer fails, or decides not, to render the content it used to render – that is a problem Microsoft want to avoid.
— Mike Davies, Internet Explorer Reality, January 27, 2008
It may have indeed been a mistake of integrating the browser rendering engine, but I wonder if more fundamentally, Microsoft letting IE6 stagnate and not developing it into IE 7 until just a little while ago was a root problem. Maybe continuous, smaller and incremental updates could have let the pain be less than it is now? Hard to tell.
Legal concerns if Microsoft breaks IE?
It seems that occasionally legal concerns about breaking compatibility with new IE releases comes up as another reason for not being able to move as quickly on standards implementation as ideal. However, Mike Shaver (from Mozilla) questions the legal concerns, asking, “What would be the legal basis for a suit by a customer, given the provisions of typical EULAs which explicitly disclaim pretty much all warranty they can?”
Comments on Shaver’s post also notes that changes to their operating systems (XP to Vista for example) and application compatibility problems seem not to raise such solutions, by comparison, despite concerns raised by even the likes of the Korean government and their banks who had to tell their population to delay upgrading to IE7 (because they had developed to IE6).
Shaver is hinting that legal issues may not be a hindrance as much as made out to be (though other practical concerns might still be).
IE8 passing the Acid2 CSS test won’t matter for most sites
A little while back, Microsoft announced that some development version of the IE8 code was passing the Acid 2 CSS test.
This led to a lot of praise in web development circles that maybe finally Microsoft was moving forward. But there were those expressing cautious optimism, too.
And the latter are justified; IE8 Acid 2 rendering won’t matter for the vast majority of sites that are likely not to even know about this new meta switch.
Maybe it won’t be too bad in the long run?
Many have opined that maybe IE is getting less significant now and whatever it does won’t really impact the web that much; it seems to follow these days, rather than lead.
On the other hand, Matt Wilcox, a developer who is also on the HTML 5 working group, had a really interesting perspective:
I think the new default of “stay as IE7 when no meta tag found” will enhance the uptake of web standards. Because every ignorant developer on earth is now going to be permanently stuck with IE7 rendering and behaviour. They will never get to use any of the new-shiny [features] of IE8 and above if they don’t know to include that meta tag. They won’t know to include that meta tag until they go away and learn about web standards.
— Matt Wilcox, Goodbye DOCTYPE switching, hello META targeting, January 22, 2008
Maybe this particular tax will actually trickle down? Or will it really bad for standards-based web developers?
Maybe none of this actually matters?
John Resig, in another post on the HTML 5 DocType found out that IE will render unknown doc types (such as the HTML 5 DocType) in standards mode now.
The HTML 5 DocType is simply this:
This means authors could start using the HTML5 doc type now for their HTML 4 documents.
The W3C Validator would fail though (I think), which may be problematic for some.
So would it be better to pay that little tax, or go for this DocType now?