(original) (raw)

Tuesday 22 January 2008

The IEBlog predictably announces that Web developers will have to use a tag or HTTP header to get IE to treat a page with post-IE7 standards compliance. Obviously a lot of people are going to be upset about this. I'm actually just puzzled. I see the business argument for taking this approach in the short term, but in the long term, it seems to impose a crippling burden on IE development.

The logical way to use this tag is to ship multiple engines and use the tag to control which engine is used to render each document. You "freeze" each engine after its release, avoiding making any changes to it because each change is potentially going to regress some site. Sounds simple and appealing, but there are huge problems:

• Footprint. You're shipping a lot more code, and it grows a lot with each release. If the user browses a mix of pages, you'll actually execute a lot more code too. Good luck competing in the mobile space when you ship half a dozen engines and your competitors only need one.
• Cross-version interactions. These engines have to talk to each other. I can have a document in one mode with IFRAMEs in other modes. These documents can even touch each other's DOMs, including layout-related DOM APIs. Architecture changes in a new engine might be constrained by, or impact on, the design of earlier engine releases. This raises the question of whether the DOM implementation, JS engine and other components are actually duplicated. If they are, problems multiply, but if they aren't, you can't guarantee compatibility.
• Maintenance burden. The truth is that you can't ever actually freeze those old versions completely. If a security bug or crasher bug is found in any one of those engines, it must be fixed in each engine it occurs in. Those fixes can create compatibility problems, so your "compatibility guarantee" turns out to be a mirage. But you have successfully multiplied the cost of security fixes and testing those fixes by the number of engines you're supporting.
• Attack surface. Each engine represents exposed attack surface. Sure, there's overlap in the code so you can't just add up the vulnerabilities, but each engine adds to your attack surface.

So does Microsoft have some magic technology that alleviates these problems? Beats me. I can imagine a tool that could find common code and merge it automatically, avoiding accidental behaviour changes, but that doesn't really help much. It'll be interesting to see how it plays out.

One Aaron Gustafson says "I, for one, hope other browser vendors join Microsoft in implementing this functionality." For the reasons above, and other reasons, I seriously doubt Firefox will be interested. I'll talk more about this in a follow-up post.