embed - object - applet

Hello! Briefly, I'm new to the list and a bit scared to post since I
haven't spent much time lurking and learning what gets talked about. And I
apologize if I'm about to talk about a repeat subject. I appreciate any
reference to archived posts where I could catch up... if this subject has
been hammered-out already.

ALSO, I'm not a fanatical watcher of the html specs, so try not to beat me
up too severely if I (yet again in life) put my foot deep into my mouth.

Somewhere along the dusty trail, the controversial EMBED element was
jettisoned out of the spec, and the mysterious OBJECT element appeared. In
my hobby, I build HTML markup motors for LamdaCore MOO objects (flat db
records) and MOO's are good places to use things like MIDI and WAV. 
(There's nothing like a looping cricket wav for a "Summer Cabin" moo
object!) :)

EMBED still seems to work for my sounds, and OBJECT doesn't (various
browser versions). Interestingly and likely off-subject, Netscape 6 will
show an image placed in an OBJECT element, and Mozilla m17 won't. Embeded
sound has failed on all Moz-based stuff I've tried so far, probably because
Netscape Media plugin won't register-up. 

So... what's going on with all this? If OBJECT is suppose to swallow
EMBED's duties, why not let it swallow APPLET and IMG too? APPLET can't be
hanging around just for backward compatibility, because EMBED should be
seen in XHTML-MOD too then.

I have a feeling there are some issues about mime types versus content
types here, and I seem to sense that there is some bickering and "strategic
positioning" going in the area of plugins and helper apps. Apps are
fighting with each other to be "your wav player".

In long, I question why APPLET (and maybe IMG) is still hanging around.
Let's beef-up OBJECT until it has the meat'n'potatoes to "embed" anything.
Then we've finally gotten around to writing a better EMBED element which is
probably what should have been done from the get-go. Please feel free to
straighten out my thinking on these things.  Direct email is fine. Thanks!
Best wishes!

PS: I suspect that the modularization of XHTML means that we'll be
server-side checking the requesting client type, and only returning markup
from html modules that the requesting clients can deal with. Will we have
enough web client types (PDA's, Palmies) that we will need to encode the
browser type (number?) and it'll need to be looked-up in a database before
the markup motor can know what kind of markup to send? (geez, that's a
terrible sentence!) Any comments on server-side browser ID and html module
inclusion/disallowance AI is welcome too.

Received on Thursday, 3 May 2001 10:50:18 UTC