Re: proposed new tag: IMG

"Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Date: Thu, 25 Feb 1993 23:13 PDT
From: "Tony Johnson (415) 926 2278" <TONYJ@scs.slac.stanford.edu>
Subject: Re: proposed new tag: IMG
To: marca@ncsa.uiuc.edu
Cc: www-talk@nxoc01.cern.ch
Message-id: <EAEA803710000191@SCS.SLAC.STANFORD.EDU>
X-Envelope-To: www-talk@nxoc01.CERN.CH
X-Vms-To: IN%"marca@ncsa.uiuc.edu"
X-Vms-Cc: TONYJ, in%"www-talk@nxoc01.CERN.CH"

>I'd like to propose a new, optional HTML tag:
>
>        IMG
>
>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:
>
>       <IMG SRC="file://foobar.com/foo/bar/blargh.xbm"> 
>
>(There is no closing tag; this is just a standalone tag.)

I have something very similar in Midas 2.0 (in use here at SLAC, and due for 
public release any week now), except that all the names are different, and it 
has an extra argument NAME="name". It has almost exactly the same 
functionality as your proposed IMG tag. e.g.

<ICON name="NoEntry" href="http://note/foo/bar/NoEntry.xbm">

The idea of the name parameter was to allow the browser to have a set of 
"built in" images. If the name matches a "built in" image it would use that 
instead of having to go out and fetch the image. The name could also act as a 
hint for "line mode" browsers as to what kind of a symbol to put in place of 
the image.

I don't much care about the parameter or tag names,  but it would be sensible 
if we used the same things. I don't much care for abbreviations, ie why not 
IMAGE= and SOURCE=. I somewhat prefer ICON since it imlies that the IMAGE 
should be smallish, but maybe ICON is an overloaded word?

>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).

I was proposing to use the file extension (.xbm above) to tag what format the 
image was in, but with the intention that in future, when HTTP2 comes along, 
the same format negotiation technique would be used to access images.

Xbm and Xpm sound resonable to me, but do they sound reasonable for non-X 
based applications??

While we are on the subject of new tags, I have another, somewhat similar tag, 
which I would like to support in Midas 2.0. In principle it is:

<INCLUDE HREF="...">

The intention here would be that the second document is to be included into 
the first document at the place where the tag occured. In principle the 
referenced document could be anything, but the main purpose was to allow 
images (in this case arbitrary sized) to be embedded into documents. Again the 
intention would be that when HTTP2 comes along the format of the included 
document would be up for separate negotiation.

An alternative I was considering was:

<A HREF="..." INCLUDE>See photo</A>

I don't much like adding more functionality to the <A> tag, but the idea here 
is to maintain compatibility with browsers that can not honour the INCLUDE 
parameter. The intention is that browsers which do understand INCLUDE, replace 
the anchor text (in this case "See photo") with the included document 
(picture), while older or dumber browsers ignore the INCLUDE tag completely.

Comments?????

Tony