[whatwg] <video> element feedback
gazhay at gmail.com
Tue Mar 20 03:21:47 PDT 2007
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
> require that UAs implement the features using plugins or using native
> code. For example, Mozilla natively supports SVG in <embed> (it
> require a plugin). Similarly, you could see <video> be implemented
> as a
> special-case plugin. That's an implementation detail and doesn't
> 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
> to think about plugin parameters.
> This doesn't mean we have to specify everything as its own element.
> 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
> as a stop-gap until the media in question is important enough to
> special treatment, if that happens.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg