Re: IMG and FIG? -Reply

>>>>>>>>>>>>>>>
<snip!>

> To head your question off at the pass, FIG is probably dead.
> Long live
> EMBED!
> <URL:http://www.cs.princeton.edu/~burchard/www/interactive/>

Is this true (that fig is dead)?  I think this would be 
very bad, because:

1) Fig has <caption>s, and <credit>s (as well as 
overlays).

2) Fig has a superior client-side imagemap capability
(imho)

3) Since Embed, in and of itself, doesn't specify any 
content, there is no guarantee that what you put on your
page will be supported by any browser that supports 
embed.  At least with <IMG> I'm pretty sure that 
if the user is using a graphical browser, it will
support gif's and probably jpeg's.  Embed could mean
anything from mpegs to au's to POV files.

4) still images have been with us since the dawn
of history, so it only makes sense to have a 
specialized tag for them with a rich set of 
corresponding attributes.

Another thing I'm worried about, and this isn't just 
limited to embed, are pages that are nothing but this:

<HTML>
<head><title> Necessary Information Page </title></head>
<body>

<embed src="myclosedformatdoc.doc" >
click <a href="http://www.closedformat.com" >
here</a> to down-load the closed format-veiwer
that lets you view this document. BTW: hope
you are running a machine that this viewer 
supports.
</embed>

</body></html>

In which case HTML ceases to be a document format, 
and instead becomes the simple glue for other formats.

I'm not saying that <EMBED> is a bad thing, I just think 
that it's not a direct replacement for <FIG>

<snip!> 
> That being the case, it's worth making sure the IMG-based
> client-side imagemapping proposal is really, really good before
> it's widely deployed. We can't rely on FIG to show up later and
> save the day.

Well, not with people saying "Fig is dead".


> <<<<<<<<<<<<<<<

Received on Thursday, 14 December 1995 13:06:21 UTC