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