Web browsers are big, bloated, monolithic things. Even the simplest browsers, such as Lynx, are fairly complicated: they have to be capable of parsing a URL, downloading data through various protocols, caching it, and displaying it to the user in a form appropriate to the type of document. These, however, are distinct activities, which can - and arguably should - be handled by distinct apps.
Using run-mailcap or something equivalent is a good first step in this direction. Given a filename and (optionally) a MIME type, it will figure out what standalone program to invoke to display the file. We need something similar for the other side: something that, given a URL, will invoke the appropriate standalone program for handling that protocol. This app should be invokable from the command line. Similarly, the protocol handlers should be runnable independently from the system as a whole. Their output could be sent to a file (if caching is desired) or named pipe (if it isn't). When you select a link in the HTML viewer app, it would do something along the lines of "download [URL] > [filename pulled from URL]; run-mailcap [filename again]". Ideally, all the apps involved should be kept small and lightweight enough that you don't mind the fact that they're getting invoked over and over again, much as you don't complain when a script runs "ls".
Reasons for building a browser on this basis: You can't crash the whole browser; at most, you can crash one process at a time. It's more in line with Unix design philosophy. Due to the intense modularity, it's easy to replace or rewrite components. Sometimes you just want one component of a browser - an HTML viewer, say, or an HTTP downloader - without all the extra baggage of a complete browser.
Unfortunately, a lot of web sites rely on inline images, and that alone pretty much brings the whole idea crashing down. (I won't even get into the problems posed by things like javascript or the "target" parameter in href tags...)-- baf, Mar 03 2000 HyTime http://www.hytime.org/HyTime is a now-eclipsed SGML-based hypertext system that's a lot more "distributed" in intent than HTML. Notably, the HyTime notion is that you should be able to embed hyperlinks in any type of SGML document; applications would collaborate with a "linking service" to provide hypermedia without putting everything into a single browser. [egnor, Mar 03 2000, last modified Oct 05 2004] HOSS http://www.csdl.tamu.edu/hoss/"Hypermedia Operating System Services is an attempt to move hypermedia functionality into the core operating environment of the computer itself." That might seem like more integration, not less, but (as with HyTime) the idea is to allow any application to easily become "hypermedia-aware". [egnor, Mar 03 2000, last modified Oct 05 2004] Cyberdog and Opendoc http://maccentral.m...03/09.opendoc.shtmlCyberdog was the browser framework and toolset, and Opendoc was the component architecture. Great idea by Apple, baked by a consortium including IBM, had its bandwagon smooshed by Microsoft's competing architecture, went stale and given to the birds! [blitzberg, Oct 04 2004, last modified Oct 05 2004] Sounds a bit like gopher, gopher://gopher.micro.umn.edu/ , which was eclipsed by HTTP and Netscape for some of the same reasons you list.-- johan, Mar 03 2000 I miss Gopher. FTP too. Two casualties of the "flashy is better" culture. If they take away my last UNIX shell ISP, I'm moving to a cabin in Montana...-- Uncle Nutsy, Aug 02 2000 Believe it or not, Internet Explorer is actually quite componentized. The HTTP protocol stack, HTML parser, layout engine, JavaScript interpreter, etc. are all independent components with reasonably well-defined interfaces. (They're not separate executables; they're mostly linked via COM.)
The biggest problem with what you propose is that it wouldn't be sufficiently incremental or reactive. (See my much maligned "spreadsheet os" idea for a possible solution, albeit a terribly overengineered one.) For example, good luck enabling progressive rendering or even making the "stop" button work sensibly with such a framework, let alone supporting scripting and DHTML.
The Unix pipe model just isn't very well suited to some applications, and a Web browser looks like one of them. (GUIs in general are a problem.) That doesn't mean it's not possible to break these applications apart, it just means we need a different component model.-- egnor, Oct 22 2000 random, halfbakery