2009/2/19 Matthias-Christian Ott <o...@mirix.org>: > On Thu, Feb 19, 2009 at 12:07:16AM +0100, hiro wrote: >> > I think the only way is dropping HTML and CSS altogether and going >> > with something new. I'd be very interested in contributing. I think >> > the replacement should not only focus on presentation but equally on >> > forming a base for less suckish applications which are highly network >> > transparent. >> > >> > Kind regards, >> > --Anselm >> >> Not sure if OP really wanted to do this, but such alternatives have >> always existed. Look at gopher for example. >> >> I would export 9p filetrees and mount them in acme. You can use text >> files and plumbing if you want hyperlinks. >> I very much enjoy reading 9fans that way. >> >> But I admit this not being beauty typesetting. >> >> > browsers like Mozilla Firefox have terrible default typographic style >> > and using text-mode browsers like links often seems to be only solution >> > when reading longer texts. >> >> I don't really get this: Where can we find real typographic style in links? > > There's actually none, but it's better to display the text in a fixed-font > uniform size than in misproportioned text with unsuitable spacing. > >> Perhaps we need a combination of Troff's beauty and web browser's dynamics. > > What do you mean by dynamic? AJAX? I suppose you mean hyperlinks.
Well, here is what I realized during the st development and which emerged into some text (g)ui library which can be seen as graphical curses at some point and which I'm going to consider forming the base of replacing HTML+CSS and vt100 and curses and all that stuff (and which I'm afraid to publish in its current flaky and unfinished state still but I need to do so anyways sooner or later). Apart from presenting information (which can be done in a terminal-like sense, and a browser is a terminal to some extend) which used to be HTML in the past, it is very obvious that there is the demand for so called "web applications" which run as hybrids remotely and locally and which are simply loaded (instead of physically installed) on every access time again and again... They can access local and remote resources in a kind of transparent way and provide services -- even if it's just about reading a bolg article. There are 3 layers in such an approach: - resource access - resource - scripting The resource access should be done using a stateful protocol rather than HTTP. The resource itself isthe content (could be something that replaces HTML+CSS+JS and provide extensions such as map() for mapping contents rendered by server- or client-side code and extensions for scripting). The scripting layer is also an extension with access to the server and client environment (not necessarily bound to the resource only). One can compare it to JS -- though I doubt the DOM-based approach of how web pages are scriptable nowadays is right. In the case of a terminal, the resource is a tty session, the resource access is the connection to it and the scripting are the commands send back and forth (which are not restricted to the resource itself, which could be a shell process, but which could be control sequences as well (server- and client environment access). So if you consider the modern Web as consisting of terminal servers providing content then we get closer to the idea. I think designing the HTML+CSS replacement must go hand in hand with the underlying protocol. Kind regards, --Anselm