Required argument is SRC="url".
This names a bitmap or pixmap file for the browser to attempt to pull
over the network and interpret as an image, to be embedded in the text
at the point of the tag's occurrence.
An example is:
(There is no closing tag; this is just a standalone tag.)
This tag can be embedded in an anchor like anything else; when that
happens, it becomes an icon that's sensitive to activation just like a
regular text anchor.
Browsers should be afforded flexibility as to which image formats they
support. Xbm and Xpm are good ones to support, for example. If a
browser cannot interpret a given format, it can do whatever it wants
instead (X Mosaic will pop up a default bitmap as a placeholder).
This is required functionality for X Mosaic; we have this working, and
we'll at least be using it internally. I'm certainly open to
suggestions as to how this should be handled within HTML; if you have
a better idea than what I'm presenting now, please let me know. I
know this is hazy wrt image format, but I don't see an alternative
than to just say ``let the browser do what it can'' and wait for the
perfect solution to come along (MIME, someday, maybe).
Let me know what you think.........
Software Development Group
National Center for Supercomputing Applications
This is an excellent idea. I'd like to make some suggestions:
1. Have ALT="alternative text" be an optional argument (surely you
mean "attribute"?). This text would be shown on those browsers
which cannot view or have been set not to view the image file
itself. A suggested browser action for <IMG> tags that do not have
that attribute would be to show an ugly grey box, or perhaps the
2. If you wanted to be really clever about it, you might implement a
tag called <FIG>, or maybe <INSERT> or <OBJECT>, that would provide
a framework for handling any format for information. This would
include images, but also video and even text. I expect that as the
Web grows larger, there will be a lot of interest in _including_
text rather than _transcluding_ it (to use Ted Nelson's terms):
that is, to be able to have a standard block of text that could be
made to show up _in_ each one of people's Web pages rather than
being linked to _by_ those pages.
Further, this tag could require the closing tag. This would allow
for older browsers to degrade gracefully: if they cannot show the
required media type, or if they do not recognize the tag at all,
they could process what is between the opening and closing tag in
the normal fashion; on the other hand, if they both recognize the
tag and can handle the media type, then they could do so and ignore
whatever is between the opening and closing tags.
In fact, incorporating your idea of using MIME, that may even be a
way of identifying the media type of a file without actually
Finally, a side effect of this would be that you could nest these
pairs of tags, which would provide several different options: if a
browser cannot handle inline video, then the next set in could
refer to a static image. The most internal set of all, of course,
would be text. (Or, if <IMG> is implemented separately, then an
<IMG> with alt text.)
3. You might consider adding the further attributes of "height" and
"width" so X-Mosaic can set aside space for the image while it
loads the text: this would reduce the "jumpiness" I suspect would
occur if an image suddenly loaded in the middle of text one was
reading. I'm not as sure about this, since it reduces the
"object-orientedness" of the Web and would be confusing if the
given width and height were different from the true values:
perhaps there is a better way of dealing with this?
4. Is your news server functioning normally? Your posting reached my
site rather late. Certainly well over two months after the date I
would have expected to see it. Well, it's as timely now as it
would have been then.
5. Or perhaps it's your posting software. "X-Mailer: Mozilla 2.0
(WinNT; I)" can cause some strange problems. Why not use rn like
the rest of us?