About the object tag

[campax]

My question is quite simple: why do we have "audio", "video" and "embed" tags?

Everything you can do with those, can be done using the more general "object"

XHTML1.1 went in the direction of making "any media content" an object, and I agree with that (altough you can't deprecate img)

But with embed (that was not part of html 4 altough supported by netscape based browser) and audio - video, that are completely new?

Ok, you may reply that video has many video-specific attributes (loop-autoplay-controls). Object actually has infinite attributes, just use appropriate params.

Ok, you may say that video provide video-specific ecmascript interfaces, and they're really useful, I agree. But we need is not video or audio specific bindings, what we really need is a consisten javascript framework to interact with any plugin.

Moreover, I was wondering where are code / codebase / classid attributes, part of HTML 4, which allowed the user agent to easily download the plugin instead of simply notify the user. And don't forget that code doesn't need to be binary code, it could be just javascript (and it will make a sandboxed version of xbl)

Object are more general, are more extensible and most important provide a fantastic (altough not very semantic) way to provide fallback content, much better than img alt attribute.

[zcorpan]

My question is quite simple: why do we have "audio", "video" and "embed" tags?

<audio> and <video> are for embedding audio and video on Web pages, or for games or special effects. <embed> is allowed because browser interoperability is better than with <object>, and it's simpler to use. Also because many authors use <embed> and it works fine; why should the validator complain about it?

Everything you can do with those, can be done using the more general "object"

No, not really -- the media elements have audio and video specific DOM APIs that <object> does not.

XHTML1.1 went in the direction of making "any media content" an object, and I agree with that (altough you can't deprecate img)

You mean XHTML2?

But with embed (that was not part of html 4 altough supported by netscape based browser) and audio - video, that are completely new?

<embed> came before <object> in browsers. I believe one reason HTML4 didn't include <embed> was that DTDs couldn't express "any attribute is allowed". <audio> and <video> are new, yes.

Ok, you may reply that video has many video-specific attributes (loop-autoplay-controls). Object actually has infinite attributes, just use appropriate params.

Params are plugin-specific, and you can't know which plugins the user has. <audio> and <video> are plugin agnostic (indeed they might be implemented natively in the browser).

Ok, you may say that video provide video-specific ecmascript interfaces, and they're really useful, I agree. But we need is not video or audio specific bindings, what we really need is a consisten javascript framework to interact with any plugin.

Do you mean that it should be possible to say to any plugin "play video" or "pause video", etc? What should happen if the plugin doesn't do video?

<object> has many interoperability problems in browsers, and this is because it is so complex and overloaded to do lots of different things -- the lesson learnt is that we shouldn't extend it to do even more things. Hence, new elements.

Moreover, I was wondering where are code / codebase / classid attributes, part of HTML 4, which allowed the user agent to easily download the plugin instead of simply notify the user. And don't forget that code doesn't need to be binary code, it could be just javascript (and it will make a sandboxed version of xbl)

Those attributes weren't for "download the plugin" in HTML4, and browsers do different things with those attributes.

Object are more general, are more extensible and most important provide a fantastic (altough not very semantic) way to provide fallback content, much better than img alt attribute.

You're free to use <object> instead of <img alt>.

How is <object> more extensible than <video>? I would say the opposite -- <object> is such a mess today that browser vendors really don't want to extend it at all. <video> however has been extended with new features many times, and I expect it to be further extended in the future.

I agree <object> is more general than <video> -- that's the whole point. You should use <object> when there isn't a more specific element for the task at hand.

HTH,

[campax]

<audio> and <video> are for embedding audio and video on Web pages, or for games or special effects. <embed> is allowed because browser interoperability is better than with <object>, and it's simpler to use. Also because many authors use <embed> and it works fine; why should the validator complain about it?

it's not a matter of validation, it's a matter of semantics (don't forget that using appropriate css i could make any element act as embedded content - anywhere)

No, not really -- the media elements have audio and video specific DOM APIs that <object> does not.
Params are plugin-specific, and you can't know which plugins the user has. <audio> and <video> are plugin agnostic (indeed they might be implemented natively in the browser).

If a browser implemented video/audio natively:
1) it would need to implement all codecs available (why some should be more important than others?)
2) it would go against copyright laws (codecs are not generally free)
3) it would need to ship a new release any time a new codec is released

instead, browser will continue to support different content through external plugins, but they will need to hard code the conversion between DOM API and plugin specific API

Do you mean that it should be possible to say to any plugin "play video" or "pause video", etc? What should happen if the plugin doesn't do video?

I mean that it should be possible to send message to a plugin, eg. through postMessage or execCommand, passing the appropriate message, instead of using specific video/audio/whatever apis.
We already do that with integrated rich edit controls (that are handled by external, although shipped togheter, plugins), to whom we communicate using execCommand instead of using a native API.
By the way, an application should know if the mime-type supplied to the object is actually a video (and so it should be handled) or something different.

<object> has many interoperability problems in browsers, and this is because it is so complex and overloaded to do lots of different things -- the lesson learnt is that we shouldn't extend it to do even more things. Hence, new elements.

object can do everything: this is the reason it is so extensible and powerful (actually, supplying the right CLSID you can get an Excel Spreadsheet in any webpage: can you do that with <embed>?)

Those attributes weren't for "download the plugin" in HTML4, and browsers do different things with those attributes.

Those attributes meant where was the code used to embed the data in the page. This means downloading the java applet or the binary plugin.

How is <object> more extensible than <video>? I would say the opposite -- <object> is such a mess today that browser vendors really don't want to extend it at all. <video> however has been extended with new features many times, and I expect it to be further extended in the future.

I'm not asking to extend object, I'm asking to remove embed, which does exactly the same thing, and it does it worse.

I agree <object> is more general than <video> -- that's the whole point. You should use <object> when there isn't a more specific element for the task at hand.

What about a web file browser (for remote hard drives)? You can imagine something like a list of icons representing the different files and a right (or left) pane including a thumbnail of the content
to add that thumbnail there are more ways to do:
1) use img - audio - video - section - etc. depending on the different mime-type of the file hovered
2) use object

You see, the incredible extensibility of object it's a quality, not a fault

[zcorpan]

it's not a matter of validation, it's a matter of semantics
...
I'm not asking to extend object, I'm asking to remove embed, which does exactly the same thing, and it does it worse.

Browsers are not going to remove support for <embed>.

Hence, what's left is the question of whether it should be conforming -- i.e. whether the validator should complain about the presence of <embed> or not.

If a browser implemented video/audio natively:
1) it would need to implement all codecs available (why some should be more important than others?)

Same reason some image formats should be more important than others...

WebKit uses QuickTime. There's an experimental Opera build with only native theora/vorbis. So there's presedence for both approaches.

I mean that it should be possible to send message to a plugin, eg. through postMessage or execCommand, passing the appropriate message, instead of using specific video/audio/whatever apis.

But the message would be plugin-specific just like <param>s?

We already do that with integrated rich edit controls (that are handled by external, although shipped togheter, plugins), to whom we communicate using execCommand instead of using a native API.

I would argue that contentEditable is handled by the browser and not an external plugin.

You see, the incredible extensibility of object it's a quality, not a fault

Well you're free to use <object> to your heart's content, so I'm not sure what the problem is here.

[campax]

1) if you forbid embed, like html4 did, then new user agent won't implement it (and maybe neither will do new version of current useragents)

2) there are no image formats more important than others, simply there are only few formats widely distributed (jpg - gif - png - svg) - and some of them are supported through plugins (eg. svg in IE7)

maybe for ogg codecs it will be possible to implement it natively, but i don't think it would be possible for proprietary codecs (i think Microsoft would complain about a native implementation of WindowsMedia in Firefox, and so would do RealMedia or DivX) - the only exception is QuickTime, whose copyrigth is owned by Apple, which in turn distributes WebKit (yes, it is under GPL, but is mainly maintained by Apple developers)

3) they would be content specific but element (and thus plugin) agnostic
for example I could say
'stop'
and the behaviour would be dependent on which plugin is loaded (eg. for a video it would stop the video, for a java applet it would call JApplet.stop )

4) in Firefox it is handled by Midas (https://developer.mozilla.org/En/Midas), which is shipped as a part of Gecko but is developed separately
in IE it is completely separated (it is a COM component)

5) the problem is that I don't see why we should have two element (embed and object) implement badly and therefore need to write both to get cross-browser compatibility, instead of just one

[zcorpan]

1) if you forbid embed, like html4 did, then new user agent won't implement it (and maybe neither will do new version of current useragents)

Wrong. HTML4 forbid it and still UAs implemented it. Why would UAs not implement it if HTML5 forbid it?

The Web requires <embed> to be supported, and hence, UAs will support it, spec or no spec. If there's no spec, interop suffers. We're here to get better interop.

2) there are no image formats more important than others, simply there are only few formats widely distributed (jpg - gif - png - svg) - and some of them are supported through plugins (eg. svg in IE7)

maybe for ogg codecs it will be possible to implement it natively, but i don't think it would be possible for proprietary codecs (i think Microsoft would complain about a native implementation of WindowsMedia in Firefox, and so would do RealMedia or DivX) - the only exception is QuickTime, whose copyrigth is owned by Apple, which in turn distributes WebKit (yes, it is under GPL, but is mainly maintained by Apple developers)

I still don't see your point.

3) they would be content specific but element (and thus plugin) agnostic
for example I could say
'stop'
and the behaviour would be dependent on which plugin is loaded (eg. for a video it would stop the video, for a java applet it would call JApplet.stop )

Ok. I guess this could be a nice thing to have but it's probably a lot harder to do than it sounds.

4) in Firefox it is handled by Midas (https://developer.mozilla.org/En/Midas), which is shipped as a part of Gecko but is developed separately
in IE it is completely separated (it is a COM component)

So?

5) the problem is that I don't see why we should have two element (embed and object) implement badly and therefore need to write both to get cross-browser compatibility, instead of just one

We can't change history and now we're stuck with two elements. We can get both to work cross-browser (so you can use either) but dropping one of them is not possible at this point.

[campax]

The Web requires <embed> to be supported, and hence, UAs will support it, spec or no spec. If there's no spec, interop suffers. We're here to get better interop.

Spec are not only for user agents, they're also for web developer. Say that embed is supported for backward compatibility and web dev won't use it any more (and in a few years it will disappear)

I still don't see your point.

You just can't implement video natively (not all video, at least)

Ok. I guess this could be a nice thing to have but it's probably a lot harder to do than it sounds.

Why? Just, when loading the plugin shared library, instead of querying IVideo (imaginary interface exposing play() - stop() - setCurrentTime() etc.), query for the more general IPlugin, that expose a MessagePort like that used for inter views communication.

So?

So rich editing control are separate modules.

We can't change history and now we're stuck with two elements. We can get both to work cross-browser (so you can use either) but dropping one of them is not possible at this point.

You deprecated body and applet, while providing a cross-browser spec for that. Why can't you do the same with embed?

[zcorpan]

Spec are not only for user agents, they're also for web developer.

Indeed.

Say that embed is supported for backward compatibility and web dev won't use it any more (and in a few years it will disappear)

embed has never been allowed in any HTML spec prior to HTML5, and yet it has been widely used. So I don't think authors will stop using it in the next few years regardless of what HTML5 says.

You just can't implement video natively (not all video, at least)

Ok. I agree with that.

Why? Just, when loading the plugin shared library, instead of querying IVideo (imaginary interface exposing play() - stop() - setCurrentTime() etc.), query for the more general IPlugin, that expose a MessagePort like that used for inter views communication.

Because for <video> and <audio>, there are somewhere between 0 and 3 "plugins" (GStreamer, QuickTime and DirectShow) you have to talk to, and they all have pretty similar APIs, whereas with your idea (if I understand it correctly) you would have to talk to all various plugins (like Flash, QuickTime, Java, etc) that have very different APIs. You'd need to maintain a mapping spec between message and plugin API for all the plugins you want it to work with.

Plugins are quite a pain in the neck as it is for implementors without this abstraction layer in between.

So rich editing control are separate modules.

Ok.

You deprecated body and applet, while providing a cross-browser spec for that. Why can't you do the same with embed?

Right, this brings me back to the question:

why should the validator complain about it?

In the case of <body bgcolor> etc, they're attributes that were deprecated in HTML4 and authors should use CSS instead. In the case of <applet> it's because Hixie argues HTML shouldn't support plugin-specific elements (we don't have <flash> or <silverlight> either), so if you want to use Java applets you should use the plugin-agnostic <embed> or <object> elements.

[joedw]

With the current spec, would it make long term sense to:

1. Obsolete using <embed>, especially as a fallback for <object>.

Move <embed> to Obsolete, like <applet>.The only current required use of <embed> is coding around old browsers that refused to honor object and, for a period of time some hosting issues for weakly-walled content markup that was afraid of <object> without sandbox. The added @sandbox feature handles this concern in those applications, I think.

So, from what I understand, use of embed anywhere could show non-conformance because but not fail and its use could be discouraged at author time.

Yes, there is one spec requirement (following) that if I select a link to external content with MIME/file extension not HTML, and it has a player for that MIME, the browser should open a new window/tab with generated <embed> markup. (Is it clear how this context is related to the current browsing context?)

"4.9.6 Page load processing model for content that uses plugins
...
When a resource that requires an external resource to be rendered is to be loaded in a browsing context, the user agent should create a Document object, mark it as being an HTML document, append an html element to the Document, append a head element and a body element to the html element, append an embed to the body element, and set the src attribute of the img
element to the address of the image.

These words should be tuned to allow any embedded content instead of just image and I think embed could be dropped and use object instead for this.

Suggest content type resource defined same as <object> using served MIME or inspection.

Suggest address of the 'img element' should be absolute URL of external content resource.

I am guessing the biggest problem with this is how to answer the question: "How do you obsolete something that was never specced?"
Let's just skip that question and just obsolete it.

Thanks and Best Regards,
Joe


.

[zcorpan]

With the current spec, would it make long term sense to:

1. Obsolete using <embed>, especially as a fallback for <object>.

Why?

"4.9.6 Page load processing model for content that uses plugins
...
When a resource that requires an external resource to be rendered is to be loaded in a browsing context, the user agent should create a Document object, mark it as being an HTML document, append an html element to the Document, append a head element and a body element to the html element, append an embed to the body element, and set the src attribute of the img
element to the address of the image.

These words should be tuned to allow any embedded content instead of just image

It seems this is fixed already. Are you reading the Editor's draft or an older version?

and I think embed could be dropped and use object instead for this.

Why?

Suggest content type resource defined same as <object> using served MIME or inspection.

I don't follow.

Suggest address of the 'img element' should be absolute URL of external content resource.

Why?

[joedw]

joedw wrote:

With the current spec, would it make long term sense to:

1. Obsolete using <embed>, especially as a fallback for <object>.

zcorpan wrote:

Why?

Sorry slow getting back here, but so many whys ...

<embed> should be obsoleted because this step would present an excellent way to discourage its use, especially as a fallback content container in an <object> element.
The only possible case for using <embed> is for old browsers that failed to implement <object> in a reasonable way. These include old browsers that ignored W3C totally concerning <object> and more recently old browsers that knew about <object> but would actually fail if they encountered @classid. In the first category, authors that support NS4 would then see that NS4 or earlier is the only use for <embed>, and authors targeting the second category could see that it is no longer necessary to worry, because recent and current latest versions of everything else are OK.

joedw wrote:

"4.9.6 Page load processing model for content that uses plugins
...
When a resource that requires an external resource...

zcorpan wrote:

It seems this is fixed already. Are you reading the Editor's draft or an older version?

Now I see it in:
"6.11.6 Page load processing model for content that uses plugins
...and set the src attribute of the embed element to the address of the resource. "

That looks fine, except,

joedw wrote:

and I think embed could be dropped and use object instead for this.

zcorpan wrote:

Why?

Because <embed> is really obsolete. If an author is told about the actual very limited subset of browsers that are out there that need <embed> then the author would probably not use it. Also, although it is traditional to use that autogenerated <embed> element to open a new context there is very little chance that a the user will be using a browser that needs <embed> for this case (usually clicking a link with a recognized file extension).

So once again, <embed> is obsolete for every case except the the very limited subset of all browsers currently out there.

I think another great reason to obsolet <embed> is that it is the last remnant of the long string of pairs that sometimes are involved in <embed>. The other use was in the feature string of .open and that has now been dropped, and in fact ignored, as I last saw it. While ignoring this string is probably not the best idea for <embed> it is simple to recode using <param>s instead.

And, if <embed> is gone from this usage, then some poor novice won't view source on the thing and see the obsolete use of <embed> in the autogenerated code and think that is the good path.

Finally, any use of embed can be handled by a straighforward restyling to <object> syntax with <param>s. Although some plugins are tuned for <embed> and vice-versa, no existing plugins will be excluded by not encouraging embed. And if there are, well then the author would know it and it would be OK because even though it is 'officially' obsolete, <embed> will probably be supported.

I don't really have anything to grind about obsoleting this what is arguably a maybe the last artifact of the GBWs, but the worst thing that could happen is I get introduced to some current tools that actually need <embed>.

Thanks and Best Regards,
Joe

[zcorpan]

joedw wrote:

With the current spec, would it make long term sense to:

1. Obsolete using <embed>, especially as a fallback for <object>.

zcorpan wrote:

Why?

Sorry slow getting back here, but so many whys ...

<embed> should be obsoleted because this step would present an excellent way to discourage its use, especially as a fallback content container in an <object> element.

It's not clear to me that it would be useful to discourage it's use.

When you don't need fallback, <embed> is basically equivalent to <object>, just less markup.

The only possible case for using <embed> is for old browsers that failed to implement <object> in a reasonable way.

No. Another possible case for using <embed> is for including, say, Flash on a page, for all browsers.

joedw wrote:

and I think embed could be dropped and use object instead for this.

zcorpan wrote:

Why?

Because <embed> is really obsolete.

It's only obsolete if we say that it is obsolete. Per the current spec, it is not obsolete.

If an author is told about the actual very limited subset of browsers that are out there that need <embed> then the author would probably not use it.

Actually, a lone <embed> works better cross-browser than a lone <object>.

I think another great reason to obsolet <embed> is that it is the last remnant of the long string of pairs that sometimes are involved in <embed>. The other use was in the feature string of .open and that has now been dropped, and in fact ignored, as I last saw it. While ignoring this string is probably not the best idea for <embed> it is simple to recode using <param>s instead.

I don't follow.

Finally, any use of embed can be handled by a straighforward restyling to <object> syntax with <param>s.

<img> can also be handled by a straightforward restyling to <object> syntax. It doesn't follow that <img> or <embed> should be obsoleted.

[joedw]

zcorpan wrote

It's not clear to me that it would be useful to discourage it's use

.

I see that. It is useful to discourage its use because it is an archaic structure that uses syntax not found anywhere else. See, <object> 'fixed' <embed> by giinvg an orderly authoring interface.

No. Another possible case for using <embed> is for including, say, Flash on a page, for all browsers.

Like I said, Flash was one of the first and <embed> got tuned for it. However, of course even Flash will run from <object>. I just know authors love the great string sometimes used to set up the plugin.

It's only obsolete if we say that it is obsolete. Per the current spec, it is not obsolete.

Hi, I get that. I just don't understand why.

Actually, a lone <embed> works better cross-browser than a lone <object>.

If so, that is too bad. True at some point in the past, but not in my current experience from what I see now, I think I probably have a better chance of getting <object> going anywhere.

Besides, the recommendation for Flash is currently <object> with fallback to <embed>. The reason for the fallback? In case the host doesn't do <object>. That reason is appropriate for authors that target some really old hosts, so is now useless as a tactic unless one of your buddies has NS4. Then you either need it or you gotta tell your buddy to update. I really don't think there are many of those folks around.

joedw wrote:

I think another great reason to obsolete <embed> is that it is the last remnant of the long string of pairs that sometimes are involved in <embed>.

I don't follow.

Then you are writing <embed> elements for very simple things that don't need any commands or parameters. Remember that long string of commands you may need to send? In <object> they are <param>s. In <embed> they are a quoted string li>ke the old .open. Just mostly uneditable or at least difficult to deal with, that is all.

<img> can also be handled by a straightforward restyling to <object> syntax. It doesn't follow that <img> or <embed> should be obsoleted.

Here we are discussing a live, scriptable object that may wish to use services via the DOM. "Dead' elements don't count. Really, I don't think <img> has a place in this conversation. I brought it in because the old spec test mentioned it (now changed).

You hinted that there might be some plugins that wouldn't want to use <object>. Are there any really?
You also hinted at better cross-browser operation with <embed>. My examples don't show that, but the landscape changes with each update so I will check more. I try to keep track because any W3C browser that has trouble with <object> has to be off the main list of usable tools. Fortunately I don't find them anymore
Likewise for any plugin that 'needed' <embed>. But I don't think there are any of those.

Are small footprint mobile browsers limited to <embed>?

Thank You and Best Regards,
Joe

[zcorpan]

I see that. It is useful to discourage its use because it is an archaic structure that uses syntax not found anywhere else. See, <object> 'fixed' <embed> by giinvg an orderly authoring interface.

Ok.

Like I said, Flash was one of the first and <embed> got tuned for it. However, of course even Flash will run from <object>. I just know authors love the great string sometimes used to set up the plugin.

Which great string are you referring to?

Hi, I get that. I just don't understand why.

I guess because it's at least equally well supported, and because it's less verbose in syntax, and doesn't seem to have any bad effects.

If so, that is too bad. True at some point in the past, but not in my current experience from what I see now, I think I probably have a better chance of getting <object> going anywhere.

It's great that object works better now than a few years ago.

Besides, the recommendation for Flash is currently <object> with fallback to <embed>. The reason for the fallback? In case the host doesn't do <object>. That reason is appropriate for authors that target some really old hosts, so is now useless as a tactic unless one of your buddies has NS4. Then you either need it or you gotta tell your buddy to update. I really don't think there are many of those folks around.

I agree that this is outdated advice.

Then you are writing <embed> elements for very simple things that don't need any commands or parameters. Remember that long string of commands you may need to send? In <object> they are <param>s. In <embed> they are a quoted string li>ke the old .open. Just mostly uneditable or at least difficult to deal with, that is all.

In <embed> they are normal attributes, where the attribute name is equivalent to <param name="..."> and the attribute value is equivalent to <param value="...">. Maybe we're talking past each other but I don't understand why it's more difficult to deal with.

Here we are discussing a live, scriptable object that may wish to use services via the DOM. "Dead' elements don't count. Really, I don't think <img> has a place in this conversation. I brought it in because the old spec test mentioned it (now changed).

Ok.

You hinted that there might be some plugins that wouldn't want to use <object>.

Did I?

You also hinted at better cross-browser operation with <embed>. My examples don't show that, but the landscape changes with each update so I will check more.

It was certainly the case a few years ago (around 2005). If object works better now, then that's great.

I try to keep track because any W3C browser that has trouble with <object> has to be off the main list of usable tools. Fortunately I don't find them anymore
Likewise for any plugin that 'needed' <embed>. But I don't think there are any of those.

Ok.

Are small footprint mobile browsers limited to <embed>?

Not that I know of.


To summarize, the reasons you want <embed> to be obsolete are

1. it is an archaic structure that uses syntax not found anywhere else
2. parameters with embed are more difficult to deal with
3. many people using embed are using it with an object parent, which is ugly and unnecessary
4. object has good browser support

While the reasons I see why <embed> should not be obsolete are

a. it has good browser support
b. it is less verbose than object
c. doesn't seem to have bad effects

Do you think this is an accurate summary? Could you elaborate on 1 and 2?

[joedw]

> To summarize, the reasons you want <embed> to be obsolete are:

Thanks for organizing this. Well first of all, this forum just killed the best most persuasive responses you could ever believe when the line dropped, or something. I will try again, but at least I calibrated myself to understand that this is not about how <object> replaces or subsumes <embed> because <audio> and <video> do that for some specified MIMEs. Rather, just that perhaps <embed> has served its noble purpose and can be retired from the list of best practices.

> 1. it is an archaic structure that uses syntax not found anywhere else

Maybe so. I see better practice is <embed> attributes now.
name="value" instead of a long string. However, it is hard to tell which are real html attributes and which are proprietary plugin attributes.

> 2. parameters with embed are more difficult to deal with

In principle, it is the same info <object> a least lets us know which of the parameters are 'standard' attributes and which are negotiated interfaces.

> 3. many people using embed are using it with an object parent, which is ugly and unnecessary

If an author goes through <audio> and <video> and the improvements offered by <iframe> and still can't find the @type that needs to be interacteid with, then where should the landing be? If it is the Flash player, then tutorials they see will show the object with nested embed - and no final fallback if embed didn't play. Anyway, first they learn object then they learn to copy that into embed. They do this as an incantation that works for, I hope, all the wrong reasons. I think these days the embed will never get executed. If it does, then something else is probably wrong tht won't be found out except by big surprize later..

> 4. object has good browser support

At times, <embed> has been judged more secure that <object>. For example in emerging multiple media social networking, the hosts may have just denied <object> and always used <embed>. With a known system where there is no competition for the mime then embed works fine and the interfaces are easily and mostly invisibly controlled ny limiting the attribute list. Some of the best people in the world have worked long and hard to get <embed> to work safely.

Nowdays, <object sandbox> options give all this functionality in a more versatile and extensible package.

> While the reasons I see why <embed> should not be obsolete are

> a. it has good browser support

It has good browser support because it has always been there.
Will mostly work in DOM0. I had my personal history story about how first, to actually get a live object that could be scripted from the host page and how that got carefully tuned for some great plugins, then how <object> arrived to bring another sort of order to the struggle.

Security precautions and workarounds dominated the early and mid efforts to publish plugin content other than preferred low risk audio and video. It took a while for everyone to get here but here we are. <object> works everywhere in a evolving and now to me somewhat more stable and predictable environment that pays proper attention to how plugins can register mimes and file extensions.

> b. it is less verbose than object

Yes, <object> and @data are more keystrokes than <embed> and @src and bunches of extra characters in <param name='...' value='...'> for every nondefault plugin parameter iinstead of <embed name='value'> or even the very simple parameter strings I have seen.
But keystrokes saved is not a true issue in this environment.

> c. doesn't seem to have bad effects

Right, except the obbious diversion of learning something mostly useless except for special cases yet to be determined.

> Do you think this is an accurate summary? Could you elaborate on 1 and 2?

The only reason fo <embed> to stay in the main line is if it is needed to serve its current role as a last gasp attempt at fallback content. Maybe it would be useful in an authored fallback role with <audio> and <video>. That may be more simple and obvious than fallback to <object>, if there is such a needed fallback mechanism in those elements.

Before I get dropped again,
Best Regards,
Joe