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