Absolutely: although most browsers seem to assume that the SRC attribute
of an IMG tag always refers to a "image/gif" resource, effectively the
media type of the resource should not be known until the resource is
fetched; the "Content-Type:" header then determines the media type.
As Dan Connolly put it:
> I like the idea of scrapping <app> for <applet>, and scrapping
> <applet> for <fig>. The media type of the resource idicated by the SRC
> attribute of the FIG is not generally specified in the markup, any
> more than the media type of a resource indicated by the HREF attribute
> of an A tag. The media type is discovered during the information
> retrieval.
In this context, <IMG> and <FIG> are merely ways of specifying that the
media be somehow *embedded* into the document when it is presented; as
concerns this <INCLUDE> idea, for instance, there is no reason why "text/html"
can't be the "Content-Type:" of a <FIG>.
If i could digress for a moment on <INCLUDE>: i agree that the
ability to include referenced HTML is certainly needed and very useful.
But i don't really see that a new tag needs to be created. There's a
problem with *directly* inserting HTML source into a document, because
there's no way to guarantee that the syntax will remain correct (stick
a <BOLD> in the middle of a document, and you screw up the entire rest
of the document). Furthermore, what happens when included subdocuments
have their own style sheets? This is why it makes sense for an included
HTML subdocument to be displayed off in its own area (like a figure box),
where it cannot directly affect the main document.
So, i propose a more general approach to presentation of referenced
resources. As i see it, there are four presentation/retrieval
methods, only two of which we use extensively at the moment.
These are the four possible combinations of IN-BAND or OUT-OF-BAND
retrieval, and EMBEDDED or EXTERNAL presentation.
1. OUT-OF-BAND resource, EMBEDDED presentation
This is what everyone refers to as the "inline image", although
i think it would be more consistent to use "inline" to refer to
an IN-BAND resource. In any case, this should not simply be the
"inline image" but the "inline anything" -- image, video, or
audio media, applet, HTML, and so on.
2. OUT-OF-BAND resource, EXTERNAL presentation
By this i refer to what happens with an <A HREF="...">. The
resource is retrieved from another source, and when it is
fetched it is presented separately from the original document.
At the moment, this always requires a user-generated request
(except, perhaps, in the case of Netscape's REFRESH).
This is where we currently have reasonably diverse media-type
support; media resources are presented outside the browser,
usually by a separate program or module, with the one exception
that "text/html" replaces the current document in the browser.
Some style-sheet implementations refer to style sheets this way,
through a link to a separate file.
In general, we don't use IN-BAND resources much. Here i'm referring
to having the data of the resource as part of the retrieved document
itself. The document itself is IN-BAND, of course, and all of the
usual markup tags are IN-BAND data.
3. IN-BAND resource, EMBEDDED presentation
This classification could apply to current tags that include some
specification about their appearance, like <HR WIDTH=50 ALIGN=CENTER>,
for instance. But i'd really like to see something like
<FIG TYPE="text/gif" ENC="base64">
..
</FIG>
or even
<FIG INBAND>
Content-type: text/gif
Content-transfer-encoding: base64
..
</FIG>
This is what i'd call a real "inline" image, and could be very useful
for small icons or figures that are intended to act as part of the
text. Including something like this in the document is far more
efficient than opening a dozen new HTTP connections to get images
averaging 100 bytes each. Also, this would be an easy way to set
out text boxes, just by inserting IN-BAND html, or to include short,
quick applet scripts.
Arena currently uses this method to include style-sheet information.
4. IN-BAND resource, EXTERNAL presentation
This method of retrieval and presentation really isn't used yet.
An example of an instance would be a case where an applet script
requiring its own window were to be included IN-BAND in a document.
Things like sounds, for instance, don't really have their
presentation defined as EMBEDDED or EXTERNAL, either.
-------------
I know this could be a little hard to map onto the currently existing
tags. It almost seems as though the tags <A> and <IMG> were designed
around their media types rather than their presentation methods.
OUT-OF-BAND resources have the option of being retrieved automatically or
upon request; this makes six possibilities out of which we only use two.
What we have is:
<A> refers to an OUT-OF-BAND, EXTERNAL resource, requiring explicit request
<IMG> refers to an OUT-OF-BAND, EMBEDDED resource, automatically retrieved
I was considering, for instance, suggesting that multiple references be
allowed in a hypertext link, such as
<A HREF="http://somewhere/mypage.html" HREF="http://somewhere/mysong.mid">
which would get these two resources either simultaneously or sequentially,
and present them together. This suggestion overlaps the use of OUT-OF-BAND,
automatically retrived resources, of which the closest thing we have now is
just Netscape's REFRESH.
I'm afraid this turned out to be rather philosophical, not practical.
I'm sorry that i don't have more time at the moment to further explore the
possibilities and be more specific about ways to implement them
effectively and efficiently. Hopefully i'll be able to do that soon.
Please give me your ideas and opinions! I welcome all your suggestions
and criticisms.
Thanks for reading.
Ping (Ka-Ping Yee): 2B Computer Engineering, University of Waterloo, Canada
kryee@csclub.uwaterloo.ca | 62A Churchill St, Waterloo N2L 2X2, 519 886-3947
CWSF 89, 90, 92; LIYSF 90, 91; Shad Valley 92; DOE 93; IMO 91, 93; ACMIPC 94
* Amano Ai * Tendou Akane * Hayakawa Moemi * Skuld * Hiyama Hikaru *
New! <http://csclub.uwaterloo.ca/u/kryee/> Yeah, i finally made a home page.