disintegrated browser

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...)