Go Molly! Go!

Finally, some progress from IE thanks to Molly’s tenaciousness.

It’s sad that it took Molly rhetorically tackling BillG on the topic to get more than witty asides out of the IE team, but beggars can’t be choosers. To that end, we (the web development world at large) need to continue to follow up, not by asking for particular features, but by demanding continued openness and progress. We developers have suffered many broken promises and decrepit stewardship when it mattered most and the IE team has been harshly rebuked as a result. It’s no wonder, then, that they’re circumspect about promising anything concrete. To that end, I’m going to be focusing my questions to the IE team on some that I’ve previously blogged here. Namely:

  1. When will your next beta or alpha be available?
  2. What about the version after that?
  3. Is your organization standardizing the new stuff you added in the last stable release? Where?

These questions are explicitly designed to avoid trapping IE (or any other browser vendor) in a set of promises which they can’t keep or forcing them to run laps in a standards body before they are ever allowed to try out anything new. Instead these questions focus on what we most fundamentally need: to know that the web will improve in a fashion relatively in line with past beneficial improvements.

Invent. Deploy. Standardize. In that order.

With that as the central goal, these questions also explicitly de-prioritize standards compliance in favor of larger improvements to the fabric of the web. A fully standards compliant IE8 won’t buy the web any serious ammunition in the war to be the continued platform of choice for building new classes of applications. Only invention and real competition can spur those kinds of advances, and prioritizing standards compliance of any renderer above more radical and powerful forms of simplification (new tags, other HTML 5 features, Gears, etc.) seriously harms the web’s chances against obvious closed-platform plays like Flex and Silverlight. We’ll need standardization to solidify gains introduce in new renderers from any vendor, but without deployed solutions, the standards process is adrift in a sea of vaguely good ideas without market forces providing a prioritizing force.

This isn’t to say that standards aren’t important (or even critical), only to say that for the web development community to insist on that above all else is to miss the forest for the trees. Once we get answers on progress, we must obviously begin to ask about specifics, but the web development world must come to understand that without a commitment to real future progress, even amazing point releases or full standards compliance won’t get us to where we want to go. We owe the IE team the breathing space to deliver something great, and they owe us a commitment to real, hands-on stewardship of their rendering engine.

Lets not miss an opportunity to move forward because we’re stuck on the past, lest we all wake up one day to realize that in bickering about the late 90’s we lost the important battles of the ’00’s by default.


  1. Posted December 8, 2007 at 8:37 am | Permalink

    Wow Alex. The most impressive article in your blog until now. Hopefully Microsoft (and the others) is hearing what your are saying.

  2. Posted December 12, 2007 at 11:57 am | Permalink

    If Microsoft can improve Internet Explorer by coming up with new proprietary features or by implementing standardized features that other browsers already support, you think it would be better to come up with new proprietary features? I cannot even begin to understand that in the slightest.

    Look at the hundreds of proprietary features that Microsoft introduced with little-to-no documentation. Look at the hundreds of well-defined standardized features that Microsoft has yet to implement.

    Which look better to you? For me at least, the standardized features look a hell of a lot better than the proprietary ones produced by Microsoft.

    Browser implementors should compete at implementing standardized features, not compete at developing incompatible poorly-defined new proprietary features.

One Trackback

  1. […] I think that statement alone is enough to indict Opera’s anti-trust actions as stupid and ill-considered. But we should also recognize that it forms the basis of Opera’s grievances. We should all be pissed off that the discussion today hinges on how we will get MSIE to improve by slight degrees (or should we expect more?). Opera could have done better, though, by shipping Gears and working with Google to make it a host for pluggable renderers…like Opera. Too bad Opera has prioritized proving a point over actually improving the situation. But I digress. […]