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

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

--- Comment #11 from Glenn Adams <glenn@skynav.com> 2011-07-23 12:51:24 UTC ---
I have no interest in debating the examples parameters I used in my original
bug report; they are real parameters taken from current, in-use HTML usage, and
as such, there are UAs or UA plug-ins that interpret them meaningfully.

data-* attributes are intended to be interpreted by client side script, and
explicitly not interpreted by the UA (or a plugin), so that mechanism is out of
scope for the resolving the parameter problem, unless UA implementers and
external spec writers willfully violate that prohibition

in order to effectively use video/audio elements in practice, an equivalent,
extensibility mechanism such as param is required to communicate to the UA
parameters that are not presently defined by video/audio element attributes;

while it is possible that some such parameters may over time be added to
video/audio as standardized attributes/properties, I have no intention of
proposing any such standardization at this time, as that was not the purpose of
this bug report;

the purpose of this bug report is to record and prompt action on the asymmetry
that has developed between object and audio/video with respect to parameter
extensibility support; if object supports this mechanism, then audio/video
needs to as well, if for no other reason, to facilitate a transition from use
of object to use of audio/video;

(In reply to comment #9)
> (In reply to comment #7)
> > inline for a couple of comments on specific examples
> > 
> > (In reply to comment #5)
> > > (In reply to comment #4)
> > >
> > > "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.
> > 
> > not if the agent intended to interpret this parameter is the UA itself, that
> > is, if the prohibition on UA interpretation of data-* is to be maintained
> 
> So, what is the UA supposed to do when it reads "quality=high"? Is it supposed
> to request a different resource to the one given in the @src attribute? If so,
> then we have to specify an algorithm for this in the HTML spec and we have to
> specify how to change the URL based on such a parameter etc.
> 
> It is not as simple as just adding a unspecified "param" attribute if the UA is
> supposed to interpret the value. It's not the same as with a swf or silverlight
> plugin, where the understanding of the value of the param attribute has been
> compiled into the plugin by the provider of the plugin and the server and
> plugin know what to do with it.
> 
> But let me take a larger guess at this parameter: it is probably valuable in
> relation to HTTP adaptive streaming, for which we will want to measure on a
> continuous basis the quality of the video that is playing back and for which we
> will want to specify an algorithm according to which the UA will change the
> HTTP request that it makes to the server for getting a lower or higher
> "quality" (well, rather: bandwidth) resource. That is something we haven't yet
> specified for HTML5 and are continuing to work on.
> 
> First in line for this is the specification of quality metrics for video
> playback, see bug 12399. Once that is specified and exposed to JavaScript, it
> is possible to write a HTTP adaptive streaming approach in JavaScript. Later we
> can progress towards specifying such an approach right inside the browser.
> 
> 
> > > 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?
> > 
> > this is a directive provided by the content author to be interpreted by the UA;
> > the UA is defined (and published) with semantics for allowfullscreen; because
> > the intended recipient of this directive is the UA itself, then it can't use
> > data-*  if the prohibition on UA interpretation of data-* is to be maintained
> 
> As I said: this is likely not a functionality that we even want to implement in
> the browser (and indeed: a data-* attribute will not solve this problem). We
> would require a @nofullscreen content attribute or something like it (just like
> we have just specified a @muted attribute). If this is functionality that is
> requested, then we have to discuss the use cases for it and decide whether they
> make sense. Right now, we have bug 12903 to discuss fullscreen.
> 
> 
> > > 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.
> > 
> > not if the agent intended to interpret this parameter is the UA itself, that
> > is, if the prohibition on UA interpretation of data-* is to be maintained 
> 
> How is the UA supposed to interpret that parameter? It would need drm
> algorithms compiled into the browser to interpret such an algorithm and do
> something with it. The DRM issue has not been resolved yet. And in fact I don't
> think we've had much of a discussion about the need for DRM on video in HTML
> yet other than stating that any specification of DRM algorithms in the browser
> would be futile. Right now the answer to the DRM need is: use flash in an
> object/embed tag.
> 
> I do believe, however, that we should have the discussion about DRM for
> audio/video. There may be a means to solve the issue without implementing DRM
> directly in the browser. Maybe some sort of private/public key system that
> could be applied to encrypting content? I haven't thought about the issue hard
> enough to come up with a solution. And we obviously haven't got a solution for
> images either. So if you have some clever ideas that still work within an open
> standard, it would be good to have such a discussion.
> 
> 
> 
> > > The "windowless" parameter is not relevant for the Web context.
> > 
> > yes it is if the agent intended to interpret this parameter is the UA itself,
> > that is, if the prohibition on UA interpretation of data-* is to be maintained
> 
> The "windowless" parameter for swf files influences how the swf is displayed on
> the Web page: either in a "window" (similar to a css block) on the page, or
> overlayed on top of the content on the page (i.e. "windowless"). See e.g.
> http://blog.ggshow.com/index.php/wmode?blog=11 for some explanations. "wmode"
> had to be defined for Flash because it's not native content on the page.
> <audio> and <video> in contrast are native to the page and they have all of CSS
> available to them for styling. Therefore "windowless" is not relevant to Web
> content, because there is no "window of the plugin" that the Web page has to
> deal with.
> 
> 
> > > 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.
> > 
> > DLNA connection manager parameters are not co-extensive with the URL protocol
> > (scheme) field, so the value of the src attribute is not sufficient; in this
> > case, a DLNA enabled user agent intended to interpret this parameter;
> 
> The way I understand http://msdn.microsoft.com/en-us/library/aa468340.aspx,
> that parameter is meant to communicate from a server to a client what protocols
> the server supports for retrieving this file so that the client can choose the
> best available protocol to choose for downloading.
> 
> All Web browsers understand HTTP and if no protocol is given in a resource URI,
> they will use HTTP for downloading that resource. So, if you want a resource to
> be downloaded with rtsp instead, you have to change the URL. E.g. your example
> will change to
> 
> <audio>
>   <source src="rtsp://yourserver.com/path/audio.mp3">
>   <source src="http://yourserver.com/path/audio.mp3">
> </audio>
> 
> 
> > > I haven't seen a parameter yet that requires a "param" attribute.
> > 
> > that's because you don't seem to recognize that each and every one of this
> > examples requires specific UA interpretation and responses to the parameter;
> 
> A UA that is not aware of what the parameters mean cannot interpret them.
> 
> 
> > such responses are not expected to be define in HTML5, but in external
> > standards/specifications (or as private agreements);
> 
> If they are important enough use cases, they should be in HTML5 and the UA
> should interpret them. If not, then data-* will be sufficient IMO.
> 
> 
> > however, a standard
> > mechanism for authoring and interchanging such parameters between the content
> > author / server and the UA *is* required;
> > 
> > the fact that param is widely used with video/audio resources via object is
> > sufficient proof that an equivalent mechanism is needed on video/audio
> 
> No. Most of the common parameters that were used in Flash are now content
> attributes in HTML. If you believe there are other parameters that should be
> standardised (as you seem to indicate), then you should take each and every one
> of them forward for standardisation.

-- 
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:51:26 UTC