Joel Spolsky wrote an article about the IE8 engine modes. The article starts with good and insightful general technology strategy wisdom and then proceeds to make bad specific conclusions.

The Insightful Part

The general compatibility strategy treatment in the article with the example of Martian plugs is very good. Everyone who works on Web specs needs understand compatibility and network effects. Joel has a history of being insightful on applications of microeconomic theories to software—particularly the network effects of complements.

Drawing the Wrong Conclusions

After the insightful general part, the article proceeds to make two mistaken assumptions along these lines:

1. IE is the primary and necessary DHTML/Ajax/Web 2.0 development platform.

2. Standards are written by idealists who don’t understand economics, business or compatibility strategy.

Platform

I live in one kind of reality distortion field—where people don’t use or need IE. I, my girlfriend, my parents, my grandfather and most of my friends from university use either Mac OS X or Ubuntu (or both). Those friends (of computer science background or otherwise) who do run Windows tend to run Firefox or Opera—not IE.

Joel seems to live in another kind of reality distortion field—where “98% of the world will install IE8”. (It’s a “high as a kite” kind of reality distortion field.)

Joel seems to be assuming a world where the way IE 5 through 7 behave is the only serious DHTML/Ajax platform around. That is, the conclusions he draws after presenting the general technology strategy insightfully are based on the assumption that IE is the platform and the Web standards aren’t. After the IE dungeon time, this is no longer the reality against which conclusions should be drawn. In reality there’s another serious DHTML/Ajax platform—the standards-based one implemented in Gecko, WebKit and Opera. The fact that people like me and people around me can live in the Gecko/WebKit/Opera reality distortion field shows that the IE part of the reality is today much less important than the Martian mindset of Microsoft apologists assumes.

So the current platform situation is that there’s the standards-based multi-vendor platform and there’s IE. From the Web app developer point of view these overlap to a great extent—the problems are the divergent bits. Web 2.0 apps run on both platforms. You don’t need the old IE runtime to participate on the Web (the Boeing intranet and Windows help files you burned on a CD-ROM in 1998 are not part of the Web). The argument Joel puts forward assumes that IE is the preferred and necessary development platform. And that’s where the conclusion goes wrong.

Today, the standards-based multi-vendor platform implemented by Gecko, WebKit and Opera not only works for Web users but is the preferred platform for developers. IE is a legacy platform that gets the backport. When Microsoft tries to bring the next IE closer to the standards-based multi-vendor platform, the breakage isn’t caused by defects in the standards-based multi-vendor platform—after all, Gecko, WebKit and Opera work with real sites and Web apps. The problem is that sniffed IEness is tainted by the old IE platform.

Where can we find a case study of addressing this issue successfully before? The answer is the default browser of Mac OS X.

Mac OS X used to have a default browser that used the Tasman engine. Then the browser based on that engine was discontinued and Mac OS X got a default browser that uses the WebKit engine. Different engines, successfull transition. How did that happen?

First, there are things that are not relevant:

1. It is not relevant that the engines came from different companies in the Mac OS X case.

2. It also isn’t relevant that the browsers had different UI brand names (although it did help with user expectation management).

3. The reason why Mac OS X changed browser engines is not relevant.

The relevant parts are:

1. The new browser did not report its UA string as a new version of the old one. Instead, it spoofed itself as an unrelated browser it was more compatible with (Mozilla).

2. The old browser was kept as an optional install for a few years.

So emulating the Safari success would involve giving IE8 a new UA string identity, making document.all evaluate to false as an if condition, and keeping the old Intranet Explorer as an optional side-by-side install for a few years.

Standards

The other mistake Joel makes is assuming that standards are necessarily written by idealists who don’t understand market realities or well-known compatibility strategies or who think it is more expensive to change the spec than to change shipped software.

Indeed, there are examples of utter disdain for well-known compatibility and network effect leveraging strategies in the Web standard space. Consider, for example, what happens in legacy text/html browsers when XHTML+SVG documents served as application/xhtml+xml.

It doesn’t have to be that way, though. Specs can be written to codify behavior that is compatible with existing software products. This is how the parts of HTML5 that deal with existing functionality are defined.

Furthermore, specs can be written to describe well-defined behavior with all inputs. Draconian failure on error is not the answer to the problems of Postel’s law. Draconian error handling creates an unstable equilibrium in Game Theory terms—it only lasts until one player breaks the rule. One non-Draconian XML5 implementation in a key client product and the Draconian XML ranks would break. Well-specified error recovery is the right way to implement the liberal part of Postel’s law. This is how CSS and the HTML5 parsing algorithm are defined.