[Bug 13333] audio, video (and source) elements require param children or equivalent

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13333

--- Comment #4 from Glenn Adams <glenn@skynav.com> 2011-07-23 05:11:47 UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > The fact that param is defined on object, and made use of regularly in the
> > manner I describe, and since it is the intent that audio and video elements
> > supplant the use of object, it is necessary to retain this usage or provide an
> > equivalent.
> 
> embed and object still exist. <audio> and <video> are only there for audio and
> video resources.

But embed and object do not support HTMLMediaElement interface or
functionality, such as timed text tracks, media controller functionality, etc.
If you would like to add these to object and embed, then I would agree that
object and embed could be used, but I've been led to believe that the idea
behind audio and video was to move away from object and embed. However, there
is now an inconsistency between object/embed and audio/video, since the former
support param and the latter do not.

It *will* be necessary to provide something equivalent to param on audio/video
to permit these tags to be used in many existing contexts, e.g., in a Home
Networking UPnP/DLNA context where DLNA specific parameters are required to be
specified by content author and interpreted by the UA.

I expect external specifications that define profiles for HTML5 in a Home
Networking context to require specific UA behaviors around the use of
parameters on audio/video, so the use of data-* for this purpose would seem to
conflict the explicit prohibition to the contrary. I would prefer having an 
HTML5 define standardized mechanism for specifying such parameters. If you
don't like introducing param, then provide an alternative; however, param seems
the logical choice.

> > > Also not that swf or sliverlight files are much more than just audio or video
> > > resources and can thus not be used in audio and video elements. So, those
> > > examples are not really valid.
> > 
> > Oh? Why not? There is nothing in the definition of audio or video that preclude
> > its use. There are no restrictions placed by HTML5 on the media type referenced
> > by these elements. Since swf and silverlight can represent audio and video
> > content,
> 
> I don't know enough about silverlight to comment, but I do know that swf does
> not represent audio or video content. Instead, it represents a player that can
> play back audio or video content. That is very different.

If you don't like the swf example, then substitute flv and the nothing else
changes.

> > why shouldn't they be reasonable examples. In any case, the problem
> > described here is independent of the examples, and stands on its own without
> > requiring use of these particular formats.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Saturday, 23 July 2011 05:11:53 UTC