Quidquid latine dictum sit, altum videtur

September 5, 2000

I've been thinking about web browsers and Microsoft's claims that web browsing functionality is "naturally" part of the operating system. I've gradually come to think that the idea here is reasonable, even though Microsoft's implementation is not.

As I see it, modern web browsers generally perform four seperate but related functions. They are:

  1. Acting as an HTTP client. That is, being able to communicate with web servers, downloading and uploading files, and so forth.
  2. Rendering HTML documents. That is, decoding web pages and formatting their text for presentation. This involves a number of sub-tasks (some extremely complicated, like handling Javascript and CSS) and frequently generates additional HTTP requests (to fetch embedded images, for instance).
  3. Storing bookmarks and history. This part of web browsing tends to fade into the background, but that's mostly because modern browsers handle it poorly.
  4. Presenting an interface to the user. Specifically, things like the "back" button and the various ways of interacting with bookmarks and history.

In the perfect computer world of my imagination, these four functions would be provided by different programs. That sounds strange, I know, but even simple things like saving a file to disk involve multiple pieces of software these days. By splitting the web browser into funcitonal units, we increase their usefulness.

How would this work in practice? Through integration with the operating system. Not in the Microsoft "use our browser or nobody's" style, of course. I suggest something closer to the Internet Config system on the Macintosh: The user would be able to select a preferred HTTP client, HTML renderer, and URL manager and any software which needed these functions could use the chosen programs.

If a default HTTP client is available, any program can download a file off the web, say for fetching their next version or sending a shareware fee. If a default HTML renderer is available, any program can display web pages, perhaps for showing HTML-encoded e-mail or online help or simply displaying an HTML document the user is writing. If a default URL manager is available, then users no longer need to worry about transfering bookmarks if they switch browsers and any program which accesses a URL can store it in the history.

The scheme presented above can be generalized further. Other file transfer protocols could have default clients. Other file types could have default renderers. Imagine a web browser that could display an HTML file downloaded from the web just as easily as one downloaded from, say, FreeNet. Imagine being able to browse efforlessly between HTML files, PDF files, and QuickTime VR panoramas while still being able to click "back" if you make a wrong turn. In any program, you'd be able to select a URL and mark it as something to check out later. And if your HTML renderer gets an upgrade, then all your programs that use it display pages better.

Is this possible? Yes. Some of this functionality is already partially available. The modules within Netscape Communicator can all call on Netscape's HTML renderer, but it isn't available to anything else. Any program on Windows can use Internet Explorer to download off the web or display HTML, but they can't do the same with any other browser. The Mac OS provides a built in HTTP client, but it's primitive and can't be replaced with something more sophisticated (so far as I know). A number of third-party URL managers are available, but they need special hooks in order to integrate with web browsers. Apple's Cyberdog allowed for exactly the flexibility I'm talking about, but is dependent on the now-defunct OpenDoc architecture.

Note the difference between my scheme and Microsoft's. Windows provides this sort of functionality to applications, but requires them to get it from Internet Explorer. (This is because Microsoft was primarily concerned with destroying Netscape, but that's another story.) I propose instead a flexible, open architecture allowing users to pick their favorite components, no matter where they came from. I'm not sure it will ever happen, though. Microsoft has no interest in this flexible a scheme, the Mozilla project is busy making their browser bigger and more monolithic, instead of breaking it into functional units. Nevertheless, I remain hopeful that I'm not the only person to see things this way.