Re: proposed new tag: IMG
marca@ncsa.uiuc.edu (Marc Andreessen)
Date: Fri, 12 Mar 93 22:32:12 -0800
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Message-id: <9303130632.AA14200@wintermute.ncsa.uiuc.edu>
To: timbl@dxcern.cern.ch (Tim Berners-Lee)
Cc: www-talk@nxoc01.cern.ch
Subject: Re: proposed new tag: IMG
In-reply-to: <9303022225.AA07248@dxcern.cern.ch>
References: <9303022225.AA07248@dxcern.cern.ch>
X-Md4-Signature: bfd43bcf4a749aaee7c69eeb202da3de
Back to the inlined image thread again -- I'm getting close to
releasing Mosaic v0.10, which will support inlined GIF and XBM
images/bitmaps, as mentioned previously. So I just reread the
exchanges we had a while back, and have a few comments...
Tim Berners-Lee writes:
> Let the IMG tag be INCLUDE and let it refer to an arbitrary document
> type. Or EMBED if INCLUDE sounds like a cpp include which people
> will expect to provide SGML source code to be parsed inline -- not
> what was intended.
We're not prepared to support INCLUDE/EMBED at this point; it raises a
number of nasty issues that are quite separate from the idea of
inlined images. For example, what happens if one EMBEDS a document
that in turn EMBEDS the first document? Oops. Aside from this, I'm
not sure I see the point in allowing arbitrary EMBED's for things like
chunks of texts: this is a hypertext system, after all, and it ought
to be possible to get the functional effect of an EMBED by using an
ordinary link. Right?
So, we're probably going to go with <IMG SRC="url"> (not ICON, since
not all inlined images can be meaningfully called icons). For the
time being, inlined images won't be explicitly content-type'd; down
the road, we plan to support that (along with the general adaptation
of MIME). Actually, the image reading routines we're currently using
figure out the image format on the fly, so the filename extension
won't even be significant.
Cheers,
Marc
--
Marc Andreessen
Software Development Group
National Center for Supercomputing Applications
marca@ncsa.uiuc.edu