I had an opportunity about a month ago to work with the Microsoft Internet Explorer team to help improve the browser. It was an extraordinarily tempting offer, and it was largely due to family pressures on my part that I reluctantly decided that it was just not possible to do it. The interview was exciting, I had a chance to talk first hand to a number of senior people with the team, and it has left me with a considerably changed impression of both Microsoft and their developers’ aspirations in producing the best product possible. If circumstances has been a little different (if I hadn’t moved to Canada late last year) then I suspect this would have been a Microsoft post you’d be reading now.

One thing that I realized, however, was that the Internet Explorer team has an amazing opportunity if they seize it now. Through a number of circumstances, one piece of technology that was never incorporated into the IE browser was a module capable of handling XHTML. Now, this may seem to be a fairly trivial omission - XHTML isn’t exactly blazing through the commercial sky yet as a must have technology (though its getting there) - but I’ve come to believe that in fact XHTML may be the key to one of the biggest problems that they face with IE - the problem of vendor legacy.

Millions upon millions of websites have adapted to the ideosyncracies of the IE browser when displaying their web pages, and in all too many of those cases, the adaptations are systemic because the HTML code is generated rather than hand-rendered. Most web portals are not updated manually anymore - they are built in generated pieces, the pieces are munged together through other generators, and the whole is often locked behind infrastructures and SOX legislation. For most such sites, changing the way that IE handles HTML is an extraordinarily disruptive occurence, one likely to cost potentially upwards of a billion dollars over the globe to fix.

What’s more, some of IE’s biggest “customers” are other applications within Microsoft, most notably Office. A change in the HTML rendering and interpretation would have severaly bad effects on product stability, and so one of the biggest points of inertia for IE is in fact these internal customers rather than customers in the outside world.

XHTML is not HTML. Yeah, it looks reasonably similar, but it does have a different syntax, a somewhat different rendering style, and perhaps most importantly, is namespace aware. IE’s HTML rendering has some basic understanding of namespaces, but HTML 4.0 by itself is not generally namespace aware and the kludges involved in making it so have not been widely adopted yet by industry.

What this implies is that development of XHTML will necessitate the creation of an entirely new rendering module with the IE framework, one that is completely separated from the HTML renderer. Now, here’s where things get interesting. Should Microsoft create such a module, there will be no vendor legacy to deal with … now. You can create W3C conformant CSS interpretations and it will not disrupt anyone’s workflow or require anyone to go back into mountains of legacy code to change a few dozen lines of code. You can introduce proper support for namespaces that can more effectively bind into the browser, making it easier to adopt an SVG or XForms layer - and moreover may be able to open this functionality to third party vendors to do the same thing (and can even put in support for a XAML-lite if that proves to be attractive).

XHTML is about more than just a cleaner way of writing HTML. It makes HTML modular in a consistent fashion without the necessity of waiting for subsequent releases of the browser to incorporate such tags, and reduces the amount of “ad-hoc” tagging that the current engine tends to encourage. It makes incorporation of alternative namespaces feasible in a memory manageable way. It extends what can be done with AJAX-oriented systems. Especially given the largely auto-generative nature of the web, as well, by dealing with XHTML as a separate namespace and mime-type, it means that a web site producer can choose to develop an XHTML version of a site concurrently with their HTML version site without significant pain or outage, then can migrate over to an XHTML system entirely just by flicking a switch when that version of IE becomes sufficiently disseminated.

The resulting XHTML (and CSS) can be guaranteed to be conformant with the W3C standards, and in the end Microsoft has a solid XML-based browser that may actually be competitive again with the still popular Firefox browser and a recently turbocharged Opera and Safari browsers. The IE team can also regain a certain level of autonomy for improveming the browser without having to be beholden to the Office team or other product teams at Microsoft; this freedom is CRITICAL if Internet Explorer hopes to have the opportunity to compete in what’s rapidly becoming a wild spree of innovation everywhere else.

I’d like to see it happen. For all that I take Microsoft to task, I also recognize that there’s a hungriness in some of the new development teams (and make no mistake about it, the MS Internet Explorer team is remarkably new, and very hungry) who want to get beyond the “we can’t make these changes because it would cause pain to our legacy customers” crap and really show their chops. Give them the chance to prove themselves, as this particular card comes along very seldom.

XHTML represents a chance to safely wipe the slate clean, to start again from scratch even while sheltered within the chrysalis of the old IE shell. Barring a complete revision of XML (something I see as unlikely for years) its a chance that won’t come again in the working lifetimes of most of the peope there, and I believe they have the talent to make it happen. It should make for an interesting next couple of years.

Kurt Cagle is the CEO of Metaphorical Web, Inc., and the chairman of the SVG Open 2006 conference.