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

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

--- Comment #6 from Glenn Adams <glenn@skynav.com> 2011-07-23 06:42:55 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > (In reply to comment #2)
> > > > > 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.
> 
> Actually, a lot changes. flv is indeed a video resource format, even though it
> is not registered as a mime type at
> http://www.iana.org/assignments/media-types/video/index.html (which I am
> actually quite surprised about). It is usually video/x-flv, while swf has
> application/x-shockwave-flash and anything can be in a swf - it doesn't have to
> be video.
> 
> When substituting flv, your params don't make much sense any more IMO.
> 
> "quality" is something that is subjective and probably only provides a label
> for a specific website that says that if it has several quality levels
> available, then choose the "high" one (whichever that is). Thus, this parameter
> can be replaced by data-quality.
> 
> As for "allowfullscreen": that is a restriction to the functionality of the Web
> browser that the Web server does not need to even be told about for retrieval
> of the resource. There is currently no means to stop a user from watching a
> video fullscreen when the browser has such functionality. And why should there
> be?
> 
> As for the drm key: that is definitely something only between the Web page and
> the Web server, so a data-drmkey attribute would be sufficient.
> 
> The "windowless" parameter is not relevant for the Web context.
> 
> And the choice of protocol to use for retrieval of a resource on the Web is
> given in a URL and not in a parameter.
> 
> I haven't seen a parameter yet that requires a "param" attribute.

you seem to be getting hung up on my examples; they really don't matter; what
matters is that object defines a use for param and that web content is using
param on object to configure various aspects of transport, playback, and
rendering of audio and video content using object;

if HTML5 intends to migrate this usage to audio/video elements, then it must
provide a counterpart, and data-* is not that counterpart because its use
precludes semantic interpretation by the UA; in all of the example I give, and
in many others I can provide, the parameter is decoded and acted on by the UA
(or associated playback component/plugin); that makes such usage dependent upon
semantic interpretation by the UA;

either HTML5 needs to remove the prohibition on UA interpretation of data-*
params, or param (or an equivalent) needs to be added;

this is not just something I am bringing up here on my own; this problem has
been recognized by commercial television service providers and a consensus
exists [1] that (1) it is a problem, and (2) needs to be addressed; it is also
my understanding that this has been recently discussed in the Web & TV IG and
perhaps the HN TF of that IG, so I expect it to move forward as a requirement
on HTML5;

if HTML5 doesn't provide this, other specification writers *will* define
equivalent mechanisms and may use data-* with specific UA semantics in willful
violation of the prohibition to the contrary; does the HTML5 authors wish this
to happen or would you like to provide a solution that you can agree with?

[1] I can provide more information on this consensus privately. Other parties
to that consensus may provide more input here or in other MLs as they see fit.

-- 
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 06:42:57 UTC