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

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

--- Comment #8 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-07-23 08:24:35 UTC ---
(In reply to comment #6)
> (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.


It is not possible for the UA to interpret random strings provided in a "param"
attribute normatively. There is no difference between providing them as
"data-*" attributes or as "param" attributes.

Therefore, HTML5's approach is to turn parameters that are important to be
interpreted by the UA into actual content attributes. So, it is indeed very
important to go through each one of the suggested parameters that you are
suggesting and analyse whether we may have missed them for specification in
HTML5. Therefore, going through each one of your examples is indeed the right
way to approach this.

-- 
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 08:24:43 UTC