On Thu, 19 Jan 1995, Daniel W. Connolly wrote:
> In response to MarcA's original proposal for an IMG tag[1], TimBL
> wrote[2]:
>
> |I had imagined that figues would be reprented as
> |
> |<a name=fig1 href="fghjkdfghj" REL="EMBED, PRESENT">Figure </a>
> |
> |where the relation ship values mean
> |
> | EMBED Embed this here when presenting it
> | PRESENT Present this whenever the source document
> | is presented
> |
> |Note that you can have various combinations of these, and if
> |the browser doesn't support either one, it doesn't break.
> |
> |A see that using this as a method for selectable icons means nesting
> |anchors. Hmmm. But I hadn't wanted a special tag.
In a previous thread, I had suggested that we needed a more generic
inline & include capability, and that serving multipart MIME content
types might be a good way to do this. However, much of the other
discussion on multipart support was as a way of packing output
together, and that use conflicted with an implied inline semantics
for multipart ( unless you were going to interpret multipart/parallel
to mean "inline" or add a new C-T: multipart/inline ), so I more or
less dropped that idea.
I now note that there is discussion on the ietf-822 mailing list
of a Content-Disposition: header ( vs. an added optional parameter
to Content-Type: ) that would, among other things, supply these
sorts of hints (inline, attached, etc.) to a MIME viewer.
( Dan Connolly : I'll gladly send you MY nickel! :-)
As others have pointed out, the other embedding issues are a real
can of worms, so I'll save that for another post.
---| Steven D. Majewski (804-982-0831) <sdm7g@Virginia.EDU> |---
---| Computer Systems Engineer University of Virginia |---
---| Department of Molecular Physiology and Biological Physics |---
---| Box 449 Health Science Center Charlottesville,VA 22908 |---