dynamic html (fwd)
hoesel@chem.rug.nl (frans van hoesel)
Errors-To: listmaster@www0.cern.ch
Date: Wed, 11 May 1994 14:43:53 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9405111239.AA00682@Xtreme>
Errors-To: listmaster@www0.cern.ch
Reply-To: hoesel@chem.rug.nl
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: hoesel@chem.rug.nl (frans van hoesel)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: dynamic html (fwd)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text
Content-Type: text
X-Mailer: ELM [version 2.4 PL5]
X-Mailer: ELM [version 2.4 PL5]
Forwarded message:
>
> As a follow up to my own message
> In which I proposed <dynamic time=200 src=URL> I would on second
> though change that proposal to
> <include refresh=200 src=URL>some initial text </include>
> and make the refresh parameter optional. So in fact the dynamic part
> is just a parameter to the yet to implement client side include.
>
> using a </include> allows one to have a browser with a switch to
> do delayed includes (just as we have delayed image now) and display
> whatever is in between <include> and </include> instead of actually
> including anything. Alternatively one could choose for the ALT=
> approuch and have <include refresh=200 src=URL alt="some text">
> and have no </include> tag. That limits however the elements that
> could be used to replace the not (yet) included element to text only
> (the value of the tag filed),
> whereas the <include></include> approach would even allow for an image
> to be seen when 'delayed include' is active (presumable a very small
> image, and the html to be include would represent a larger image.
>
> one could imagine documents that go like this
>
> <include refresh=3 src=URL>this will change soon</include>
> <include refresh=5 src=URL>this will change a bit later</include>
> etc
> and using the expire date in the data requested via the include URL to
> effectively reset the refresh time to the next century one would have
> implemented a clean way of delayed loading.
> people viewing such a page would first see a simple version and as time
> passes will gradually see a more expanded document (prossibly with large
> inlined images).
>
> other ideas come to mind:
> <include refresh=10 src="URL">this is some text</include>
> <form action=....>
> <textarea ...>
> </form>
> and depending on the cgi script behind the url's you would have an
> interactive communication : I write something in my textarea, submit
> the form, write it somewhere an other user can read it via a
> refreshed include, and I will retrieve your submitted text every 10 seconds
>
> or:
> <include refresh=5 src="URL"><audio src=""></include>
> This asumes we finally get inlined audio (don't make it too difficult, just
> play the sound when the page is presented to the user).
> If the audio sample is long enough, and the connection is fast enough you
> have some kind of radio station. (not good for music but for speech where
> breaks after sentences are not too bad this seems a good idea)
>
>
>
>
sorry for the forwarded message, but I accidently sent it to myself.
- frans