Some very interesting thoughts; I've been thinking them myself for some time. With regard to the limitations of terminals (rich media, typography, whitespace),

Some very interesting thoughts; I've been thinking them myself for some time. With regard to the limitations of terminals (rich media, typography, whitespace), these are limitations of current terminal emulators but are not an intrinsic limitation. I've often wondered about the history of the terminal emulators we use. From xterm and onward, they have all emulated a basic DEC VT-100. A historical accident, or inertia? The VT-100 wasn't very sophisticated, and most emulators don't even emulate it fully. There were much more featureful terminals succeeding it, with colour and graphics, yet we didn't add support for them. What caused this whole aspect of computing to become stuck in the late 1970s? There are also specifications like ECMA-48 which standardise control for font and size/spacing/justification and a number of layout features, colour selection and much more. It also defines separate data and presentation layers. Mostly unimplemented except for a minimal number implemented by xterm. Some emulators have also implemented rudimentary graphics, wider colour selection, unicode support and mouse reporting, but nothing truly ground breaking. It strikes me that what's really missing here is the development of a new class of terminal emulator which implements a much more advanced presentation layer. For example a full PS/PDF-style drawing model, and/or OpenGL-style graphics facilities. Combined with an extended set of control codes to manipulate the data layer, you could effectively have a browser rendering engine and DOM equivalent in terminal form. Which could be driven by any language capable of using stdin/stdout, from a shell script to Python and C++. No reason it couldn't be xterm compatible either; there's lots of ways to extend the control code space, and we already have termcap/info to add support for new functionality.