The Trouble With Browsers
December 18, 1998
Traveling away from the XML '98 conference, I had time to look back over the products-and-tools landscape. It seems to me that the server-side stuff is looking really good and the authoring picture is getting better. The browsers, though, just aren't where they should be. For browsers, read "Microsoft and Netscape" although if these guys don't get with the XML program, there may be an opening for lightweight fast-moving players to come up the middle.
The Trouble With Microsoft
So much talent, so much money, so much energy, so little to show. The XML support in Internet Explorer R5 beta 2 is a big disappointment. Yes, IE5b2 does CSS-driven display - but with bullet holes in vital organs (see the Web Standards Project report). And in conversation with Microsoft people, it becomes obvious that they really don't want to talk about XML+CSS. They do want to talk about: XSL (their snapshot is excellent, considering the standard is many months from stability), XML islands in HTML (boring), HTML behaviors (a proprietary extension and they still haven't finished the job on CSS 1.0), and DCOM/ActiveX/DNA (useful for all-Microsoft shops).
The other problem with XML+CSS in IE is that the DOM support is not really usable yet. This, in my opinion, is a completely fatal flaw. Since XML+CSS doesn't look any prettier than HTML+CSS, the only reason I can see for sending XML to a browser is so you can run some code on it once it gets there, and you can't do that without the DOM. Or am I missing something?
There must be an explanation. To this grey-bearded software veteran, constructing a good fast CSS-driven XML viewer with a DOM just doesn't seem all that technically taxing; certainly within Microsoft's reach, if they wanted to do it. I honestly, truly, don't understand the hold-up, but I've heard three moderately convincing hypotheses: the paranoid theory, the Trident theory, and the data-only theory.
The Paranoid Theory
The paranoids preach that XML+CSS+DOM is just too simple and open, and thus not in Microsoft's interest. There is evidence for this position, for example the recent Halloween memos, where Microsoft's Vinod Valloppillil saw danger in a world of commoditized standards, and preferred a thicket of arcane APIs and non-modular architectures; like, for example, DCOM or WebDAV. I don't know, even the leaders of this industry say it's OK to be paranoid, but the theory feels a little simple-minded to me.
The Trident Theory
This takes its name from the display/programming engine that first made its debut at the core of IE 4, internally code-named Trident. This theory says that Trident lives on in IE5, and that since it was mostly built before XML arrived on the scene, it just knows a little too much about HTML, and at too deep a level, ever to be easily usable for wrangling XML. There's no proof that this isn't true, and I've heard the story a couple of times from independent sources, but no Microsoftie has ever lent it even the most indirect support.
The Data-Only Theory
This theory is the one best-supported by Microsoft's public stance, which seem to be that data and documents are deeply different, that XML is for data; for boring old documents, HTML is just fine and meets the world's needs. If you believe this is true, you might well end up acting like Microsoft is, doing the minimum possible to support document-type operations. This seems like an awfully simple-minded world-view, and ignores some basic lessons of the Web experience (read my lips: everything is a document).
And of course there are some who say, sneering, that Microsoft Just Doesn't Get It, but in fact, Microsoft usually does. So what's really going on?
The Trouble With Netscape
The Netscapists are sure saying all the right things: the core display code is big and old and kludgy? Throw it out, start again. Need to parse XML? Use expat. Want stylesheets? Use the stable, well-understood CSS1. Want to program? Use the W3C DOM. What else could you want on the policy front?
But I can't view pages using policy, I need software to do that. And it's not there. I have, at various times over the past few months, downloaded Mozilla, and more recently NGLayout, and it is nowhere near ready for prime time. It crashes, it locks up, it blows the simplest CSS directives. Yes, it's pretty fast, and unlike Classic Navigator, doesn't reload the page from scratch every time you breathe on the window. The DOM support is there, but boy, don't go to near the walls or corners of that code without a hard-hat.
The XML support? Anyone who's been following the Mozilla newsgroups knows that the NGLayout code, until a few weeks before XML '98, had basically no XML support, so all that can be said is that it's not too bad for something whacked together at the last minute.
And then there's AOL, but we're not at the moment sure whether AOL is Mozilla's doting grand-dad or evil stepmother. Here's some names: WAIS, Navisoft, PLS - pretty good looking companies that were taken over by AOL and run into the ground. On the other hand, AOL's money is as good as anyone's and they have more than most, so maybe there's hope. But on balance, Mozilla being in AOL's hip pocket is a big question mark beside the future of XML display.
Hey, Children, What's That Sound?
We want to browse XML documents, we want to use stylesheets, and we want to run code in the browser. Why is this hard?
XML is one of the world's easiest formats to parse, and its error-handling rules mean that you don't have to write miles of bozo-correction code. CSS stylesheets may not exactly be a conceptual triumph, but they've been stable for years. The DOM is younger, but then there's not that much to it, and both browser companies worked hard on defining it.
Something's going on here
what it is ain't exactly clear
What is going down, anyhow?