EMBED has CAPTION and CREDIT. No overlays, although this was brought
up. It seems that the going mentality is that there's not much demand for
overlays, as applets or server-side CGI routines can do it. (The first
time I need overlays I'm gonna whack out a CGI overlayer that works like
this: /cgi-bin/overlay/source/dir?relativepathtoimage1&rpti2&...)
Also, it's been mentioned that EMBED is not the best place for such a
thing in HTML in the first place. There's been talk about doing this
with table cells, where you explicitly define cells which appear in the
same place. No serious proposals yet, but something like this might
work:
<TABLE>
<TR>
<TD> <EMBED SRC="movie.mpg">
<OVERLAY WIDTH="100%"> <IMG SRC="frame.gif">
<OVERLAY VALIGN=BOTTOM ALIGN=LEFT> Shot on location
</TABLE>
Where OVERLAY is basically identical to TD/TH in the specs and overlaps
the previously defined TD.
[Once again, this OVERLAY thingy is an *entirely* on the fly creation of
mine, don't expect to see it in HTML *ever*. But then again, if you're
on the WG and like it, feel free to steal it. ;-)]
> 2) Fig has a superior client-side imagemap capability
> (imho)
I agree. As the EMBED proposer (Paul Burchard) recently said, the FIG
method of CSIM subtly encouraged authors to write meaningful alternative
markup. MAP is missing that, which is something I dislike severly about
it.
> 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.
I don't see that as being a problem with EMBED. It is what IMG should
have been in the first place - inline some media type; and if not
inline-able spawn a helper application or save the file.
If your browser can't handle video/x-quicktime, or doesn't have a
helper app, then it should NOT send Accept: */*. And if it sees
Content-type: video/x-quicktime it should terminate the connection.
Further, you should serve media formats that are (1) appropriate and (2)
likely to have widely deployed viewers. So for video, MPEG or Quicktime
is much better than something like GL/DL or even AVI (very little
interframe compression), and certainly better than GIF or JPEG.
> 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.
Those attributes should be moved to some sort of style mechanism, in any
case.
And sound has been around longer than sight - ears are easier to evolve
than eyes - but we have *nothing* for audio support in HTML. ;)
> 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.
Looked at Adobe's page lately? They're full of things like this:
<A HREF="blah.pdf">
<IMG SRC="acrobat_icon.gif" ALIGN=LEFT>
Instructions for everything we make
</A>
<A HREF="acrobat_distribution/">
Download an Acrobat viewer for your platform here.
</A>
It's kinda sad, since most of the docs would be more readable much more
quickly in HTML. But Acrobat is a far superior format to HTML for many
things. *shrug*
I agree that using the wrong medium for a message is wrong. But I don't
think EMBED will encourage it at all. Conversely, since EMBED relies on
media types and not Netscape-like plugins, and media handlers tend to be
more portable than full apps or plugins, EMBED could make life a lot
cleaner.
> I'm not saying that <EMBED> is a bad thing, I just think
> that it's not a direct replacement for <FIG>
What FIG has that EMBED doesn't:
- overlays, which are addressable in other ways, and transcend images
- client-side imagemaps, which are addressable in other ways,
and also transcend still images.
I like FIG, but the more I think about EMBED, the processing power of
current and future machines, and the future of the web, it makes far
more sense to just go with EMBED and live with the slight differences.
> > 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".
True. But then again, I'd prefer EMBED and a decent MAP and a
table-based overlay mechanism to the (inferior) FIG mechanism. All of
those *and* FIG would be good thing as well.
That said, don't take my word for it, since I'm obviously biased - read
the specs and the WG archives, spend a few days thinking about it, then
decide for yourself and make some constructive noise.
Joshua
--
___.----~~~----.___ | MIME: jsbell@acs.ucalgary.ca
,--------.-.,-'-------------------` | WWW: http://www.ucalgary.ca/~jsbell/
`--------"-'-.,---`~~~-----~~~'
'---'-._____/