W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > July 2011

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

From: <bugzilla@jessica.w3.org>
Date: Sat, 23 Jul 2011 09:11:22 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QkYF0-0002j4-1Q@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13333

--- Comment #9 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-07-23 09:11:20 UTC ---
(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 09:11:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:14 UTC