Conveying type information to readers (was: Re: Multipart/mixed for many inline images)
lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)
Errors-To: listmaster@www0.cern.ch
Date: Mon, 11 Apr 1994 13:02:10 --100
Message-id: <94041111582050@cguv5.cgu.mcc.ac.uk>
Errors-To: listmaster@www0.cern.ch
Reply-To: lilley@v5.cgu.mcc.ac.uk
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: lilley@v5.cgu.mcc.ac.uk (Chris Lilley, Computer Graphics Unit)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Conveying type information to readers (was: Re: Multipart/mixed for many inline images)
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Length: 2171
Marc VanHeyningen wrote:
> I believe the last of these options is the only viable way to keep
> HTTP request/response but permit multiple requests to be transmitted
> in a single connection. Any solution that does not allow for the all
> the different cases of the images discussed in the example above is,
> IMHO, a non-starter.
Thanks for that very clear description of the problem. There were a lot of
things I hadn't considered, like expiry and redirect.
I was aware that HTTP/1.0 had moved from filename extensions to MIME types yet
it still seemed to use file types on the server side to perform the MIME typing.
99% of existing files on existing servers can be accurately typed by this
method. I agree that is does not always work, though, and the number of cases
where it will not work will increase as time goes on.
This does raise the problem that the user has lost some information, been
disempowered in a sense. Previously, with browsers that show the URL of links as
the pointer passes over them, you had some idea what you were fetching. An
inline image used as a link; for example. I might see (using my naive ideas of
file typing) that it is linked to large-figure.tif and deduce that it is
therefore a bigger, possibly 24 bit, version of the inline image. Then again, it
may be linked to more-on-this.html and I might (again perhaps erroneously)
deduce that I will learn more about the subject of the figure by following the
link.
In both cases, I am using typing information as an aid to my browsing or
searching strategy.
If this information cannot be relied on, what is do I use instead. And if the
URL contains no meaning, why display it in the browser?
When I write html documents I try to use meaningful document names and so on to
guide the reader. An inline gif and a larger tiff version will have the same
name but different extension, for example. Document filenames give an idea of
the document's contents.
If this is wrong, how should the writer convey this information to the reader?
I realise this has moved from a technical proposal to document design and
usability issues, so I have renamed the subject line.