Re: Generalising inlined images
kevin@scic.intel.com (Kevin Altis)
X-Delivered: at request of secret on dxcern.cern.ch
Message-id: <9310061845.AA16939@rs042.scic.intel.com>
X-Sender: kevin@rs042.scic.intel.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 6 Oct 1993 11:42:12 -0800
To: Dave_Raggett <dsr@hplb.hpl.hp.com>, Nathan.Torkington@vuw.ac.nz
From: kevin@scic.intel.com (Kevin Altis)
Subject: Re: Generalising inlined images
Cc: www-talk@nxoc01.cern.ch
At 12:03 PM 10/6/93 +0100, Dave_Raggett wrote:
>Nathan wants to be able to inline arbitary kinds of things into
>an HTML+ document:
>
>> ...and regardless of whether the HREF was to an image, a sound file or
>> more hypertext, it would be included in the current document.
>
>> How will/should this be done?
>
>Does the inlined object behaves like a character or a paragraph?
>
>Do you play sound immediately or when the user clicks the link?
>
>Do you retrieve an "inlined" Postscript file automatically or
>wait until the user clicks the link?
>
>HTML+ does provide some support for inlined linked HTML or plain text,
>but we need to clarify what we want.
Background
Right now we have <IMG SRC...> which allows you to include an XBM or GIF
image that is available via an URL or "local file." We also have <INC
SRV...> which allows you to include a text file or html/text file via an
URL or "local file" as well as run an arbitrary command such as "ls" or
"rm" assuming you're on a Unix machine, but in any case the result of
running the command either returns nothing or returns text or text/html.
"Local file" means different things depending on whether the client
software opens the HTML document on the local file system or gets the HTML
document via an HTTP server. In the former case, <IMG SRC...> and <INC
SRV...> allow the HTML document to include anything the user has access to
from their file system, while the latter restricts access based on the
privs. established on the http server providing the documents.
Yeah, yeah, yeah, we know all that, what's your point. Well, a couple of things.
I think we might be better off making <IMG SRC...> and <INC SRV...> into a
single "inclusion" tag with a modified syntax to support an arbitrary set
of inclusion types. What I have in mind is to put the MIME types into the
tag syntax so you might do <INC text/html="..."> or <INC image/gif="...">
or <INC sound/wav> or <INC x-command/. This simplifies the syntax and at
the same time allows a lot more flexibility than we currently have. The
biggest win comes when the client software has MIME to application mappings
so that when it encounters applicatin/tex then the client software passes
off the data to a "helper" application which returns the data as an
image/gif or some other type negotiated by the client and helper
application. The INC tag should also work differently than an HREF. An INC
would always mean load immediately or at least start the loading process,
though loading images and sounds could take a while, so they'll have to be
treated like inlined image loading today. An HREF could be used for user
invoked loading which might mean changing the use of HREF slightly or
coming up with a different tag.
Inlined should always behave like characters, otherwise you can't do tiling
and other important layout things.
My other problem with <IMG SRC...> and <INC SRV...> is that they do
different things depending on whether you're fetching via an HTTP server or
a client. I don't have any easy answers right now, but I forsee major user
confusion when people put together documents and test them locally, only to
find out they don't work off a server because of access privs. relative
pathing, etc. Any ideas?
ka