I do fully understand the points you make below, but I am not sure I
fully subscribe to the logic.
<embed> is in HTML5 specifically for plugins.
However, for <embed>, <object>, <iframe>, and <video>, the spec
doesn't
require that UAs implement the features using plugins or using native
code. For example, Mozilla natively supports SVG in <embed> (it
doesn't
require a plugin). Similarly, you could see <video> be implemented
as a
special-case plugin. That's an implementation detail and doesn't
really
affect the spec.
I think we have then arrived at tags-for-everything.
(<img><video><audio><embed><iframe> cover everything do they not?)
However, I think if <object> is so widely derided by everyone, than I
think it needs to be depreciated sooner rather than later.
On 20 Mar 2007, at 09:25, Ian Hickson wrote:
Similarly, for backwards-compatibility reasons, adding anything to
<object> is a nightmare. We'd have to carefully examine every
addition to
make sure it didn't clash with existing content, for instance.
Furthermore, overloading an element with various APIs results in
difficulties for authors. An author dealing with audio doesn't want to
think about aspect ratios, and an author dealing with video doesn't
want
to think about plugin parameters.
This doesn't mean we have to specify everything as its own element.
There
are media types that it doesn't make sense to support with a specific
element (at least not yet); we don't want to have six dozen
elements with
each type having its own set of features (and bugs). We _do_ have a
generic element, <object>, which does work for generic inclusion. It
doesn't support media-specific features (like the Video API) but it
works
as a stop-gap until the media in question is important enough to
deserve
special treatment, if that happens.
