Re: [dwm] [OT] Personal Website and CSS

On Thu, Feb 19, 2009 at 02:19:24PM +0000, Anselm R Garbe wrote:
> 2009/2/19 Matthias-Christian Ott <ott_AT_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).

I'm eagerly awaiting libgt to write an E-Mail client or text editor.
 
> 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.

Well, you could simply run a remote file server and let your local
applications use it (9p is quite suiteable for this). Usually you install
your software on your computer and don't load it everytime you use from
a remote server, so I don't see the need for web applications. Richard
Stallman summed it up quite good [1]. Additionally it's a performance
loose and I guess the carbon footprint of such web applications is
significantly higher.
 
> There are 3 layers in such an approach:
>
> - resource access
> - resource
> - scripting

What you propose is the following:

        data
      filtering/
     manipulation rendering displaying
/----------^---------\ /---^---\ /----^----\
+-----+ +--------+ +--------+ +-----+
| res | <--> | server | <--> | client | <--> | X11 |
+-----+ +--------+ +--------+ +-----+
\----------v----------/ \-v-/
         remote resource
        resource access

Basically it's a pipe where serveral intermediate data formats are used.

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

I think the server should only store the data and do no rendering at all.
 
> 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.

Why should server store interactive applications? We should design a
text description language (without different appearance for everyone)
and simply render it.

We already have network transparent user interfaces and file systems.

I would really like to throw away X11. So that you have a universal
hardware-implementable rendering language and system (buffer management
etc.) and an event layer on top of it. So if you want to browse a
hyperlinked document you compile it to the rendering language and run
an event manager, which handles things like scrolling, on top of it. So
you have a data pipe (model), renderer/compiler (view) and event manager
(controller).

> Kind regards,
> --Anselm

Regards,
Matthias-Christian

[1] http://www.guardian.co.uk/technology/2008/sep/29/cloud.computing.richard.stallman
Received on Thu Feb 19 2009 - 18:52:35 UTC