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

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

--- Comment #10 from Glenn Adams <glenn@skynav.com> 2011-07-23 12:42:55 UTC ---
(In reply to comment #8)
> (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.

Of course a UA can't interpret random parameters. They have to be specified via
external specs, implemented by UAs according to those specs, and then used by
content authors in a compliant manner, where compliance is outside the scope of
HTMl5.

data-* attributes are intended to be interpreted and acted on by client side
script; an entirely different purpose, which is why there is a prohibition on
UA semantics;

> 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.

no, no, no... i do not intend to go down that path; my only intent in providing
examples was to show that they have real uses, i do not want to propose any
standardized HTML5 semantics for any of these parameters;

what is needed is the generic, enabling mechanism of param as currently found
on object; you may view it as an extension mechanism or as an enabling
mechanism for private agreements between content authors and UA implementers;

if HTML5's HTML syntax supported a generic attribute extensibility mechanism,
such as namespace qualified attributes found in HTML5's XHTML syntax, then that
mechanism could be used, but it is not available in the HTML syntax;

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