Tuesday 6 November 2007
I'm fascinated by the silence surrounding IE8. It suggests two possibilities: they're silent because there's nothing happening at all, or they're silent because they're cooking up something astounding. Both seem improbable; the latter, because Microsoft likes to advertise broadly and early to developers, and the former, because what was the point of waking up to do IE7 and then going back to sleep again?
Either way, they're showing little interest in implementing new Web standards such as ES4 or the WHATWG APIs (nor old ones such as CSS2.1 or DOM Events). Since ES4 is backwards compatible with ES3, the argument that it would break compatibility is bogus, but nevertheless that's their line. We heard the same thing during the IE team's three-year holiday between IE6 and IE7, interestingly enough --- the "compatibility matrix" made it too hard to do anything. Sometimes they seem to argue that they were right the first time, IE7 was a mistake and it actually was too hard.
Attitudes to compatibility are actually very interesting. Microsoft seems to take the position that any change that negatively affects a Web site is bad. Mozilla --- and our friends at Apple, Opera and elsewhere, I think --- insist that when sites rely on a bug that clearly violates a standard, we will fix the bug even if it hurts sites. (In some cases, we might push to change the standard instead, but only if the "bug" is at least tolerably sensible behaviour.) So for every major release we fix a lot of bugs, and we risk breaking sites.
I always expect Web developers to grumble about this, and every time I meet some, I ask them whether our relaxed compatibility causes them problems. The answer is invariably "no"! Or at least, the developers I meet prefer us to fix the bugs because although it may break things here or there, overall our more consistent behaviour makes it a lot easier to develop Web apps for Firefox than for IE. Almost everyone tells me they develop their sites first in Firefox, and when everything's working, they backport it to IE. (For some reason I always feel shy when I hear this.) I guess if you're going to iterate your site design, you want to do that with the browser that's easiest to work with.
Actually I think both attitudes are right, because we're addressing different sets of users. I suspect when Microsoft talks about compatibility they're largely talking about intranet sites inside corporations, which are often maintained poorly or not at all, so anything that's broken by a browser change will remain broken forever. And it's easy to see how the needs of large corporate customers can come to dominate the thinking of a software organization --- they're large accounts with focused contact and are used to getting what they want. (Hey, I worked at IBM!) As another example, we've seen how Microsoft's slow security update cycle trades off the security of home users against the convenience of large customers.
Maybe the time has come for Microsoft to split (at least at the engine level) the "intranet" browser from the "Internet" browser. Otherwise they actually risk painting themselves into a corner, where more and more Internet sites are optimized for Firefox or anything but IE. It sucks to be late to the party and having to be the third or fourth implementor of a bunch of new APIs; you've lost your say in how those APIs are designed and may be compelled to reverse engineer the behaviour of other browsers (although thanks to Ian I hope the latter is less of a problem than it used to be!).
Of course, there's a whole other perspective on this: Silverlight and .NET. "Compatibility constraints" in IE make a handy brake on the evolution of the open Web, very useful when pushing a competitor to the Web*. (Many have pointed out the big joke about Microsoft's ES4 objections, namely that C# has gone through two huge revisions in the last few years.) Shiny new platforms like Silverlight and WPF don't have to worry about compatibility now, but it will be interesting to see how they handle compatibility going forward. We're in a marathon, not a sprint, it will be a few releases before they get traction, and if they have to ship side-by-side Silverlight assemblies, one for each version they've released, it's not going to be a small download or a mobile-friendly footprint.
* It's uncouth to speculate that Microsoft's representatives might act in bad faith. Unfortunately, history shows it's a real possibility. I want to be polite, but not naive.