joedw wrote:> 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.
src, type, width and height, and all global attributes are HTML attributes, and all other are plugin parameters (although all attributes are actually passed to the plugin, I think).
I agree that it is clearer with to see with <object> what the parameters are.joedw wrote:> 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.
You mean <iframe sandbox>?joedw wrote:> 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.
Case study: doctype was shortened to "<!doctype html>", encoding declaration was shortened to "<meta charset=utf-8>", type="text/javascript" was made optional, etc.joedw wrote:> 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.
joedw wrote:> 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.
video and audio do indeed have a fallback mechanism, and e.g. http://hacks.mozilla.org/2009/06/html5- ... ks-markup/ has an example with <embed> as fallback in <video>.