This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13333 - audio, video (and source) elements require param children or equivalent
Summary: audio, video (and source) elements require param children or equivalent
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: contributor
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords: TrackerIssue
Depends on:
Blocks:
 
Reported: 2011-07-22 21:36 UTC by Glenn Adams
Modified: 2013-01-31 16:11 UTC (History)
16 users (show)

See Also:


Attachments

Description Glenn Adams 2011-07-22 21:36:12 UTC
In order to configure playback by means of audio and video element types, it is frequently necessary to specify author supplied parameters intended to be interpreted by the playback component (or plugin). Such parameters are frequently required in order to configure the playback component (or plugin) for purposes of server setup, transport setup, playback setup, rendering setup, etc.

In pre-HTML5 content, the param child of an object element is often used for this purpose. However, HTML5 fails to define param as a child element for either audio or video element types. In order to correct this deficiency, the content models for these elements should be changed to read as follows:

<quote>
If the element has a src attribute: zero or more param elements,  zero or more track elements, then transparent, but with no media element descendants.
If the element does not have a src attribute: zero or more source elements, zero or more param elements,  then zero or more track elements, then transparent, but with no media element descendants.
</quote>

In addition, the content model of the source element type should be changed to read as follows:

<quote>
Zero or more param elements.
</quote>

The purpose of allowing param element children on a source element is to permit specifying parameters on both the media element and the chosen source element such that the two sets of parameters are merged (with union operator) as the effective parameters for the media component (plugin). In this fashion, parameters that are dependent upon a particular source (among alternates) may be specified distinctly and merged with parameters that are not source specific.

Example #1 - Configure Flash Playback

<video src="video.swf">
  <param name="quality" value="high">
  <param name="allowfullscreen" value="true">
</video>

Example #2 - Configure Sliverlight Video with DRM

<video src="example.xap" type="application/x-silverlight-2">
  <param name="initParams" value="drmKey=0123456789abcdef0123456789abcdef">
  <param name="windowless" value="true">
</video>

Example #3 - Configure DLNA A/V Connection Manager for Audio Playback with RTP preference over HTTP

<audio>
  <source src="audio.mp3">
    <param name="dlna-res-protocolInfo" value="rtsp-rtp-udp:*:audio/mpeg:*">
  </source>
  <source src="audio.mp3">
    <param name="dlna-res-protocolInfo" value="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3">
  </source>
</audio>

Note that in the absence of the above mechanism, a UA implementer or external specification that references HTML5 will be forced to define some elsewhere-standardized, alternative solution that provides an interoperable means to specify such parameters. Three such alternative being considered are:

(1) an elsewhere-standardized use of data-* attributes (in willful violation of the HTML5 prohibition of such usage), e.g., data-param-foo="bar";
(2) use object instead of video or audio, in which case the new functionality defined around video and audio elements are not available;

Finally, in addition to adding param to audio, video, and source elements as described above, a case can be made that param should be added to the track element as well, since architecturally, a timed track may need or use parameter information to configure the UA for transport, playback, rendering, etc.
Comment 1 Silvia Pfeiffer 2011-07-23 04:00:17 UTC
Such params are always just useful for a particular website because of the way they have been set up. Your examples confirm this. Thus, IMO the data-* attributes seem completely sufficient to satisfy these needs.

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.
Comment 2 Glenn Adams 2011-07-23 04:39:55 UTC
(In reply to comment #1)
> Such params are always just useful for a particular website because of the way
> they have been set up. Your examples confirm this. Thus, IMO the data-*
> attributes seem completely sufficient to satisfy these needs.

I disagree. Use of these parameters are definitely *not* specific to a particular website, and, in fact, may require specific semantics in a UA. At present, HTML5 3.2.3.8 states "User agents must not derive any implementation behavior from these attributes or values. Specifications intended for user agents must not define these attributes to have any meaningful values." In contrast, the intended use of param is precisely to define meaningful values for which UAs derive implementation behavior.

The fact that param is defined on object, and made use of regularly in the manner I describe, and since it is the intent that audio and video elements supplant the use of object, it is necessary to retain this usage or provide an equivalent.
 
> 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, why shouldn't they be reasonable examples. In any case, the problem described here is independent of the examples, and stands on its own without requiring use of these particular formats.

G.
Comment 3 Silvia Pfeiffer 2011-07-23 04:58:38 UTC
(In reply to comment #2)
> The fact that param is defined on object, and made use of regularly in the
> manner I describe, and since it is the intent that audio and video elements
> supplant the use of object, it is necessary to retain this usage or provide an
> equivalent.

embed and object still exist. <audio> and <video> are only there for audio and video resources.

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


> why shouldn't they be reasonable examples. In any case, the problem
> described here is independent of the examples, and stands on its own without
> requiring use of these particular formats.
Comment 4 Glenn Adams 2011-07-23 05:11:47 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > The fact that param is defined on object, and made use of regularly in the
> > manner I describe, and since it is the intent that audio and video elements
> > supplant the use of object, it is necessary to retain this usage or provide an
> > equivalent.
> 
> embed and object still exist. <audio> and <video> are only there for audio and
> video resources.

But embed and object do not support HTMLMediaElement interface or functionality, such as timed text tracks, media controller functionality, etc. If you would like to add these to object and embed, then I would agree that object and embed could be used, but I've been led to believe that the idea behind audio and video was to move away from object and embed. However, there is now an inconsistency between object/embed and audio/video, since the former support param and the latter do not.

It *will* be necessary to provide something equivalent to param on audio/video to permit these tags to be used in many existing contexts, e.g., in a Home Networking UPnP/DLNA context where DLNA specific parameters are required to be specified by content author and interpreted by the UA.

I expect external specifications that define profiles for HTML5 in a Home Networking context to require specific UA behaviors around the use of parameters on audio/video, so the use of data-* for this purpose would seem to conflict the explicit prohibition to the contrary. I would prefer having an  HTML5 define standardized mechanism for specifying such parameters. If you don't like introducing param, then provide an alternative; however, param seems the logical choice.

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

> > why shouldn't they be reasonable examples. In any case, the problem
> > described here is independent of the examples, and stands on its own without
> > requiring use of these particular formats.
Comment 5 Silvia Pfeiffer 2011-07-23 05:40:39 UTC
(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.
Comment 6 Glenn Adams 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.
Comment 7 Glenn Adams 2011-07-23 06:55:38 UTC
inline for a couple of comments on specific examples

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

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

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

> 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

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

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

such responses are not expected to be define in HTML5, but in external standards/specifications (or as private agreements); 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
Comment 8 Silvia Pfeiffer 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.
Comment 9 Silvia Pfeiffer 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.
Comment 10 Glenn Adams 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;
Comment 11 Glenn Adams 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.
Comment 12 Philip Jägenstedt 2011-07-25 09:53:02 UTC
(In reply to comment #11)
> 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;

If there are use cases, why not just define new attributes?

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

<object> is not exactly a good role model here. <object> takes arbitrary parameters because it allows for arbitrary plugins. <video>, on the other hand, does only one thing, so there should be no fuzziness about what attributes are needed.
Comment 13 Glenn Adams 2011-07-25 11:48:52 UTC
(In reply to comment #12)
> (In reply to comment #11)
> > 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;
> 
> If there are use cases, why not just define new attributes?

Because

(1) that is not the point of this bug request,
(2) that presumes there is consensus on which parameter attributes are required,
(3) that requires possible premature standardization of parameter attributes,
 
> > 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;
> 
> <object> is not exactly a good role model here. <object> takes arbitrary
> parameters because it allows for arbitrary plugins. <video>, on the other hand,
> does only one thing, so there should be no fuzziness about what attributes are
> needed.

I've been working with video/audio formats for many years now in the context of their use with existing web content via object, and I can state with complete certainty that this set of parameters is *not* fixed, not *known* a priori, and *not* possible to standardize at this time and for all time for video/audio element types.

Though some parameters are sufficiently generic to consider for standardization as distinct attributes, e.g., "fullscreenmode", others are not, e.g., "drm*".

The fact is that object does support param. Given that it is apparently (though not explicitly) the case that video/audio elements are intended to supplant object, a similar extensibility mechanism needs to be provided for parameter specification prior to standardization of specific parameters as attributes.

As I pointed out previously, if the HTML syntax of HTML5 supported namespace qualified extension attributes such as supported by the XHTML syntax of HTML5, then this problem could be resolved through the use of non-standardized or pre-standardized attributes. However, that is not the case, and to obtain such extensibility, one should not be forced to use the XHTML syntax of HTML5.

Over time I would expect consensus to emerge over specific parameter attributes such that they can be added as standard attributes, however, this takes time, and it still does not reflect the fact that new video/audio media formats, transport protocols, digital rights management schemes, etc, are created on a regular basis with their own requirements for additional parameters that cannot be a priori specified as fixed set of known attributes.

G.
Comment 14 Philip Jägenstedt 2011-07-25 11:58:54 UTC
If the parameters and their processing aren't be standardized, then they also won't be implemented by browsers. Unlike with <object>, there is no <video> plug-in architecture to which parameters could be propagated, so only parameters that browsers understand would have any effect. Given that, Silvia's suggestion of using data-* attributes seems reasonable.
Comment 15 Silvia Pfeiffer 2011-07-25 12:01:43 UTC
If an eventual standardisation is envisaged of such parameters, and a browser
is intending to experiment with a new "parameter", they will just pick an
attribute that has not been used yet by the standards and other browsers and propose that in preparation for standardisation. For JavaScript developers, the data-* attributes are sufficient for experimentation and demonstration of a use case prior to proposing it for standardisation.

BTW: you seem to believe that <object> is deprecated. That is not the case, I
just wanted to make that clear. You can continue to use <object> with a browser
plugin, even for any needs where you have special audio and video requirements.
Comment 16 Glenn Adams 2011-07-25 12:22:32 UTC
(In reply to comment #14)
> If the parameters and their processing aren't be standardized, then they also
> won't be implemented by browsers. Unlike with <object>, there is no <video>
> plug-in architecture to which parameters could be propagated, so only
> parameters that browsers understand would have any effect. Given that, Silvia's
> suggestion of using data-* attributes seems reasonable.

I've pointed out repeatedly that HTML5 currently states in 3.2.3.8 "User agents must not derive any implementation behavior from these attributes or values. Specifications intended for user agents must not define these attributes to have any meaningful values." Unless this prohibition is removed, then what you suggest won't work.

Secondly, I did not say that parameters won't be standardized. HTML5 and W3C are not the only standards/organizations. Other organizations define profiles for HTML based UAs, and, indeed I am in the process of drafting such a profile for an organization that defines compliance requirements for devices in a home network. Requirements to support specific parameters will be defined by such profiles and UA suppliers will be required to implement specific parameters.

This will remain a fact of life of HTML5. Why? Because HTML5 does not define many behaviors of UAs. For example, HTML5 does not mandate specific support for CSS properties. So HTML5 is not the be-all and end-all for defining a UA or defining compliance between interoperable UAs.

Regarding plug-in architectures, object (in HTML5 or HTML4) does not really define a plug-in architecture. Further, there is no reason that a UA should not treat video/audio in an identical fashion to object as far as plug-in (or built-in) support is concerned. I fully expect UAs to implement support for some media types on video/audio directly, and to delegate other media types to plug-ins. That is an implementation detail of UAs, and the spec should not preclude or assume an implementation strategy.

So your statement that "there is no <video> plug-in architecture to which parameters could be propagated" is not correct since it presumes implementation details that are outside the scope of HTML5.

G.
Comment 17 Glenn Adams 2011-07-25 12:43:33 UTC
(In reply to comment #15)
> If an eventual standardisation is envisaged of such parameters, and a browser
> is intending to experiment with a new "parameter", they will just pick an
> attribute that has not been used yet by the standards and other browsers and
> propose that in preparation for standardisation. For JavaScript developers, the
> data-* attributes are sufficient for experimentation and demonstration of a use
> case prior to proposing it for standardisation.
> 
> BTW: you seem to believe that <object> is deprecated. That is not the case, I
> just wanted to make that clear. You can continue to use <object> with a browser
> plugin, even for any needs where you have special audio and video requirements.

(1) it is not appropriate for other standards organizations, e.g., those writing profiles on HTML5, to define attributes on video/audio elements; such practice is considered poor form

(2) i have stated it a number of times in this thread, but the use of param I am describing here is *NOT* intended to be interpreted by JavaScript; while that is possible, and I do not preclude it, it is beside the point for the purpose of this bug report; this bug report is addressing the need for the content author to specify one or more parameters to be interpreted by the UA for the purpose of configuring the transport, decoding, playback, rendering, or other usage of video/audio content when specified with the video/audio element types, and where such parameters are not yet standardized as content attributes by HTML5;

(3) saying "please use <object>" is not a sufficient answer unless you redefine HTMLObjectElement as HTMLVideoElement or HTMLAudioElement (according to the media type) and additionally add all the new equipment defined for use with video/audio to the object element;

So, to reiterate:

(1) using non-standard attributes on video/audio in the HTML syntax of HTML5 won't work for other defining (external) standards/specifications;
(2) using data-* won't work because that is based on JS interpretation only;
(3) using <object/> will not work because it does not implement HTML{Video,Audio}Element nor does it have the other new mechanisms of video/audio, e.g., <source> children, <track> children, etc.

G.
Comment 18 Bob Lund 2011-07-26 14:54:44 UTC
(In reply to comment #17)
> (In reply to comment #15)
> > If an eventual standardisation is envisaged of such parameters, and a browser
> > is intending to experiment with a new "parameter", they will just pick an
> > attribute that has not been used yet by the standards and other browsers and
> > propose that in preparation for standardisation. For JavaScript developers, the
> > data-* attributes are sufficient for experimentation and demonstration of a use
> > case prior to proposing it for standardisation.
> > 
> > BTW: you seem to believe that <object> is deprecated. That is not the case, I
> > just wanted to make that clear. You can continue to use <object> with a browser
> > plugin, even for any needs where you have special audio and video requirements.
> 
> (1) it is not appropriate for other standards organizations, e.g., those
> writing profiles on HTML5, to define attributes on video/audio elements; such
> practice is considered poor form
> 
> (2) i have stated it a number of times in this thread, but the use of param I
> am describing here is *NOT* intended to be interpreted by JavaScript; while
> that is possible, and I do not preclude it, it is beside the point for the
> purpose of this bug report; this bug report is addressing the need for the
> content author to specify one or more parameters to be interpreted by the UA
> for the purpose of configuring the transport, decoding, playback, rendering, or
> other usage of video/audio content when specified with the video/audio element
> types, and where such parameters are not yet standardized as content attributes
> by HTML5;
> 
> (3) saying "please use <object>" is not a sufficient answer unless you redefine
> HTMLObjectElement as HTMLVideoElement or HTMLAudioElement (according to the
> media type) and additionally add all the new equipment defined for use with
> video/audio to the object element;
> 
> So, to reiterate:
> 
> (1) using non-standard attributes on video/audio in the HTML syntax of HTML5
> won't work for other defining (external) standards/specifications;
> (2) using data-* won't work because that is based on JS interpretation only;
> (3) using <object/> will not work because it does not implement
> HTML{Video,Audio}Element nor does it have the other new mechanisms of
> video/audio, e.g., <source> children, <track> children, etc.
> 
> G.

I would like to point out that there is an existing need to pass DRM parameters to a user agent that supports that DRM. This in no way extends the functionality of the video API but instead conveys information to the user agent that it needs to fetch and decode the media. <param> would provide a way to do this. data- would also work if the restriction that Glenn cited were removed; is that a possible path.

Bob Lund
Comment 19 Silvia Pfeiffer 2011-07-26 23:55:49 UTC
(In reply to comment #18)
> I would like to point out that there is an existing need to pass DRM parameters
> to a user agent that supports that DRM. This in no way extends the
> functionality of the video API but instead conveys information to the user
> agent that it needs to fetch and decode the media. <param> would provide a way
> to do this. data- would also work if the restriction that Glenn cited were
> removed; is that a possible path.
> 
> Bob Lund

Since browsers don't support DRM, you will need to provide a browser plugin to interpret the DRM parameters, no matter in which way you put them into the HTML page. Browser plugins are used in HTML through the object and embed tags, which have a param attribute, so that should solve it. If a particular Web page needs to communicate something from the plugin with the video element, then the data-* attributes would make sense. Even if there was a recommendation ("standard") to use a particular plugin with particular params and a particular JavaScript library to do this communication.
Comment 20 Bob Lund 2011-07-27 00:28:50 UTC
(In reply to comment #19)
> (In reply to comment #18)
> > I would like to point out that there is an existing need to pass DRM parameters
> > to a user agent that supports that DRM. This in no way extends the
> > functionality of the video API but instead conveys information to the user
> > agent that it needs to fetch and decode the media. <param> would provide a way
> > to do this. data- would also work if the restriction that Glenn cited were
> > removed; is that a possible path.
> > 
> > Bob Lund
> 
> Since browsers don't support DRM, you will need to provide a browser plugin to
> interpret the DRM parameters, no matter in which way you put them into the HTML
> page.

I guess you're referring to some of the current more popular browsers. In fact, there is an activity underway defining requirements for an HTML5 user agent that supports a specific DRM in a widespread, but specialized application. In this case, the need to pass DRM related info exists. Aside from this specific requirement to be able to convey DRM specific information acted on by the user agent the video element can be used as is.

>Browser plugins are used in HTML through the object and embed tags, which
> have a param attribute, so that should solve it. If a particular Web page needs
> to communicate something from the plugin with the video element, then the
> data-* attributes would make sense. Even if there was a recommendation
> ("standard") to use a particular plugin with particular params and a particular
> JavaScript library to do this communication.

To reiterate, there is no plugin. The user agent will be expected to support a media format that includes a DRM. It is desired the HTML5 video element and all of the related features be available to Web content that runs on this browser. I think that as media delivery using new media formats become more widespread on the Web there may be other new browser implementations that will support certain aspects of these formats and there may be a need to pass information across the video element API.
Comment 21 Silvia Pfeiffer 2011-07-27 02:05:46 UTC
(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #18)
> > > I would like to point out that there is an existing need to pass DRM parameters
> > > to a user agent that supports that DRM. This in no way extends the
> > > functionality of the video API but instead conveys information to the user
> > > agent that it needs to fetch and decode the media. <param> would provide a way
> > > to do this. data- would also work if the restriction that Glenn cited were
> > > removed; is that a possible path.
> > > 
> > > Bob Lund
> > 
> > Since browsers don't support DRM, you will need to provide a browser plugin to
> > interpret the DRM parameters, no matter in which way you put them into the HTML
> > page.
> 
> I guess you're referring to some of the current more popular browsers. In fact,
> there is an activity underway defining requirements for an HTML5 user agent
> that supports a specific DRM in a widespread, but specialized application. In
> this case, the need to pass DRM related info exists. Aside from this specific
> requirement to be able to convey DRM specific information acted on by the user
> agent the video element can be used as is.


I am talking about User Agents that implement the HTML5 specification in a cross-UA-compatible way as defined by the W3C. Are you are talking about an application that supports the HTML5 specification and other extra specifications? That then goes beyond being a HTML5 UA and would not be compatible with HTML5 UAs for that extra functionality (unless used with plugins). This is be a move towards proprietary extensions that only work in specific browsers and thus doesn't help to retain the Web as an interoperable platform. Why not add such specifications directly to HTML5 and bring it to the whole Web?
Comment 22 John Foliot 2011-07-27 03:01:31 UTC
(In reply to comment #21)
> 
> I am talking about User Agents that implement the HTML5 specification in a
> cross-UA-compatible way as defined by the W3C. Are you are talking about an
> application that supports the HTML5 specification and other extra
> specifications? That then goes beyond being a HTML5 UA and would not be
> compatible with HTML5 UAs for that extra functionality (unless used with
> plugins). This is be a move towards proprietary extensions that only work in
> specific browsers and thus doesn't help to retain the Web as an interoperable
> platform. Why not add such specifications directly to HTML5 and bring it to  > the whole Web?

FWIW, a previous bug was filed (http://www.w3.org/Bugs/Public/show_bug.cgi?id=10902) that sought to address the DRM issue, and was shot down by the editor with the pithy response of "DRM is Evil". (http://www.w3.org/Bugs/Public/show_bug.cgi?id=10902#c8)

Subsequent to that, Maciej Stachowiak wrote:
"Although I personally dislike DRM, it's clearly not something Apple is entirely
opposed to as a vendor.

If anyone believes that HTML5 should change to add some form of DRM support, I
think there needs to be an example of what kind of change at the HTML level (as
opposed to inside individual media formats) would actually be helpful.

That being said, it's likely to be hard to evaluate whether any given feature
is helpful until at least one implementor is ready to add DRM support. DRM
schemes tend to be extraordinarily complicated, and making a guess in a vacuum
about what HTML may need is unlikely to be successful."
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10902#c45

I now believe that Glenn is suggesting that <param> could/would serve that purpose, and we have a hint that "...at least one implementor is ready to add DRM support."

If this bug (#10902) needs to be re-opened it must happen this week.
Comment 23 Glenn Adams 2011-07-27 04:11:55 UTC
(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #19)
> > > (In reply to comment #18)
> > > > I would like to point out that there is an existing need to pass DRM parameters
> > > > to a user agent that supports that DRM. This in no way extends the
> > > > functionality of the video API but instead conveys information to the user
> > > > agent that it needs to fetch and decode the media. <param> would provide a way
> > > > to do this. data- would also work if the restriction that Glenn cited were
> > > > removed; is that a possible path.
> > > > 
> > > > Bob Lund
> > > 
> > > Since browsers don't support DRM, you will need to provide a browser plugin to
> > > interpret the DRM parameters, no matter in which way you put them into the HTML
> > > page.
> > 
> > I guess you're referring to some of the current more popular browsers. In fact,
> > there is an activity underway defining requirements for an HTML5 user agent
> > that supports a specific DRM in a widespread, but specialized application. In
> > this case, the need to pass DRM related info exists. Aside from this specific
> > requirement to be able to convey DRM specific information acted on by the user
> > agent the video element can be used as is.
> 
> 
> I am talking about User Agents that implement the HTML5 specification in a
> cross-UA-compatible way as defined by the W3C. Are you are talking about an
> application that supports the HTML5 specification and other extra
> specifications? That then goes beyond being a HTML5 UA and would not be
> compatible with HTML5 UAs for that extra functionality (unless used with
> plugins). This is be a move towards proprietary extensions that only work in
> specific browsers and thus doesn't help to retain the Web as an interoperable
> platform. Why not add such specifications directly to HTML5 and bring it to the
> whole Web?

@sylvia

HTML5 does not define browsers; the W3C does not (currently) define compliance or interoperability (and may never do so); HTML5 doesn't even define what CSS properties are required to be implemented by a UA...

you seem to be over-estimating the role played by the HTML5 spec: browser and client specifications, compliance testing, and interoperability will be defined by other organizations, and in this process, HTML5 is just one of many specs that will be referenced;

for HTML5 to be successful in a variety of device contexts (other than the desktop), the spec must recognize the role of extensibility and the existence of external specifications;

the bug reported here is an enabling technology that facilitates use of video/audio elements in the real world of devices that extends beyond the role of the HTML5 spec itself; there are a number of other existing extensibility mechanisms already in place in HTML5; as a result, your reluctance to recognize the need for extensibility here is not entirely consistent with these facts; for example, in HTML5 and referenced specs we have:

(1) the 'args' argument on HTMLCanvasElement.getContext(...), by means of which context specific or UA specific parameters may be provided to the Canvas implementation;

(2) the 'features' argument on Window.open(...), by means of which UA or platform specific parameters may be provided to the UA/browser/client implementation;

(3) the 'protocols' argument on WebSocket constructors, by means of which UA, platform, or transport/protocol specific parameters may be provided to the UA/browser/client implementation;

(4) the existing use of param on object element;

(5) the use of namespace qualified attributes on the XHTML syntax of HTML5

etc.

These are just some examples of existing extensibility mechanisms. They are there for a number of good reasons, one of which is relevant to the current thread: namely, the standardization of such parameters takes considerable time, requires experimentation, both in development and in deployment, and rarely can be fully a priori specified.

The same holds for audio/video.

Regarding DRM, yes, this is one possible usage of these parameters, which is neither speculative nor absent from implementations of browsers as you incorrectly claim above.

It would be premature to propose any sort of DRM parameters at this time, and that is likely to remain so in the future, so probably all could achieve consensus on is a generic parameter/attribute like 'drmParameters' with an arbitrary string value, for which there is very little value-add over a simple param mechanism as currently supported by object.

If you want to advocate the standardization of such a parameter or the other examples I gave in my original submission above, then feel free to do so. However, please don't use that as a rationale through which you argue that a generic mechanism like param is not relevant. It is relevant, and will remain so in the context of video/audio replaced content usage.

G.
Comment 24 Glenn Adams 2011-07-27 04:24:49 UTC
(In reply to comment #22)
> (In reply to comment #21)
> > 
> > I am talking about User Agents that implement the HTML5 specification in a
> > cross-UA-compatible way as defined by the W3C. Are you are talking about an
> > application that supports the HTML5 specification and other extra
> > specifications? That then goes beyond being a HTML5 UA and would not be
> > compatible with HTML5 UAs for that extra functionality (unless used with
> > plugins). This is be a move towards proprietary extensions that only work in
> > specific browsers and thus doesn't help to retain the Web as an interoperable
> > platform. Why not add such specifications directly to HTML5 and bring it to  > the whole Web?
> 
> I now believe that Glenn is suggesting that <param> could/would serve that
> purpose, and we have a hint that "...at least one implementor is ready to add
> DRM support."
> 
> If this bug (#10902) needs to be re-opened it must happen this week.

I would not advocate re-opening 10902. In fact, I advocate taking NO action regarding standardization of DRM parameters (at least in the HTML5 context). What I am pointing out in this bug report is the need for a generic param mechanism by means of which arbitrary parameters (including DRM parameters) may be specified by the content author and targeted to the UA implementation (for arbitrary purposes), (possibly but not necessarily) subject to future standardization inside or outside the W3C.

Regarding actual implementations of DRM support in browsers, there is more than one browser that supports DRM of video/audio content, and which AT THE CURRENT TIME makes use of the param child on object to communicate DRM parameters. So I am not speculating about the future, but describing existing, deployed products.

Further, to reiterate, I am not distinguishing between a UA implementation and plug-in implementations. A browser is a combination of the two, and the dividing line is arbitrary and implementation specific. Consequently, any argument that param is targeted to plug-ins is not relevant from an implementation perspective. The authors of param need not know how a browser implements support for a given video/audio media type, since that partition is opaque. Browser A may implement support for video media type V as a built-in component, while Browser B may implement via a plug-in mechanism.

G.
Comment 25 Silvia Pfeiffer 2011-07-27 07:44:04 UTC
(In reply to comment #23)
>
> for HTML5 to be successful in a variety of device contexts (other than the
> desktop), the spec must recognize the role of extensibility and the existence
> of external specifications;

HTML is extensible by nature: http://dev.w3.org/html5/spec/Overview.html#extensibility .


> the bug reported here is an enabling technology that facilitates use of
> video/audio elements in the real world of devices that extends beyond the role
> of the HTML5 spec itself;

What you are advocating is the introduction of vendor-specific proprietary user agent extensions hidden under the pretense of having a standard param attribute. Whichever way you bend this: you are not advocating an open and interoperable Web with your approach.

If you want to do what you are proposing to do, it really doesn't matter if we standardise anything here in HTML: you can already introduce new attributes on elements.


> there are a number of other existing extensibility
> mechanisms already in place in HTML5; as a result, your reluctance to recognize
> the need for extensibility here is not entirely consistent with these facts;

None of your examples do the same as what you are proposing.


> for example, in HTML5 and referenced specs we have:
> 
> (1) the 'args' argument on HTMLCanvasElement.getContext(...), by means of which
> context specific or UA specific parameters may be provided to the Canvas
> implementation;

> 
> (2) the 'features' argument on Window.open(...), by means of which UA or
> platform specific parameters may be provided to the UA/browser/client
> implementation;
> 
> (3) the 'protocols' argument on WebSocket constructors, by means of which UA,
> platform, or transport/protocol specific parameters may be provided to the
> UA/browser/client implementation;

These are all parameters on function calls in JavaScript. If you wanted that, you'd ask for introduction of a new Video() constructor with a param argument.

 
> (4) the existing use of param on object element;

This is exclusively used for plugins and no matter how hard you try to regard plugin and UA core code as the same - they are not. Plugins extend the functionality of the standardised Web with proprietary functionality.


> (5) the use of namespace qualified attributes on the XHTML syntax of HTML5

Let's not go into an XHTML discussion when we are discussing HTML5.

So, I'm sorry, but I really think we're not doing the open Web a favor by introducing a hidden means for non-interoperable proprietary extensions. Content that would be published for such an extension would not play natively in all browsers. That we have such a situation today with codecs is unfortunate and should not be a mistake that we should continue to repeat.
Comment 26 Henri Sivonen 2011-07-27 12:21:30 UTC
(In reply to comment #24)
> Regarding actual implementations of DRM support in browsers, there is more than
> one browser that supports DRM of video/audio content, and which AT THE CURRENT
> TIME makes use of the param child on object to communicate DRM parameters.

What browsers are those?
Comment 27 Glenn Adams 2011-07-27 14:13:26 UTC
(In reply to comment #25)
> (In reply to comment #23)
> >
> > for HTML5 to be successful in a variety of device contexts (other than the
> > desktop), the spec must recognize the role of extensibility and the existence
> > of external specifications;
> 
> HTML is extensible by nature:
> http://dev.w3.org/html5/spec/Overview.html#extensibility .
> 
> 
> > the bug reported here is an enabling technology that facilitates use of
> > video/audio elements in the real world of devices that extends beyond the role
> > of the HTML5 spec itself;
> 
> What you are advocating is the introduction of vendor-specific proprietary user
> agent extensions hidden under the pretense of having a standard param
> attribute. Whichever way you bend this: you are not advocating an open and
> interoperable Web with your approach.
> 
> If you want to do what you are proposing to do, it really doesn't matter if we
> standardise anything here in HTML: you can already introduce new attributes on
> elements.
> 
> 
> > there are a number of other existing extensibility
> > mechanisms already in place in HTML5; as a result, your reluctance to recognize
> > the need for extensibility here is not entirely consistent with these facts;
> 
> None of your examples do the same as what you are proposing.
> 
> 
> > for example, in HTML5 and referenced specs we have:
> > 
> > (1) the 'args' argument on HTMLCanvasElement.getContext(...), by means of which
> > context specific or UA specific parameters may be provided to the Canvas
> > implementation;
> 
> > 
> > (2) the 'features' argument on Window.open(...), by means of which UA or
> > platform specific parameters may be provided to the UA/browser/client
> > implementation;
> > 
> > (3) the 'protocols' argument on WebSocket constructors, by means of which UA,
> > platform, or transport/protocol specific parameters may be provided to the
> > UA/browser/client implementation;
> 
> These are all parameters on function calls in JavaScript. If you wanted that,
> you'd ask for introduction of a new Video() constructor with a param argument.
> 
> 
> > (4) the existing use of param on object element;
> 
> This is exclusively used for plugins and no matter how hard you try to regard
> plugin and UA core code as the same - they are not. Plugins extend the
> functionality of the standardised Web with proprietary functionality.
> 
> 
> > (5) the use of namespace qualified attributes on the XHTML syntax of HTML5
> 
> Let's not go into an XHTML discussion when we are discussing HTML5.
> 
> So, I'm sorry, but I really think we're not doing the open Web a favor by
> introducing a hidden means for non-interoperable proprietary extensions.
> Content that would be published for such an extension would not play natively
> in all browsers. That we have such a situation today with codecs is unfortunate
> and should not be a mistake that we should continue to repeat.

you keep insisting that this mechanism is a vendor specific proposal, it is definitely not; it is a proposal to enable other standards, whether proposed by W3C or external organizations; it is to maintain consistency with current, real, necessary practice;

you seem to be advocating an idealistic position that presumes that HTML5 will a priori specify all useful/necessary features;

you have failed to offer a viable alternative to this proposal, all you have offered either doesn't work or violates some prohibition or convention; just to review, you have said:

* use data-*
* use non-standard attributes in HTML syntax
* use object
* use JS parameters to non-standard JS interfaces

to re-iterate why these don't work:

* use data-*

HTML5 prohibits this usage when UA is intended to interpret values

* use non-standard attributes in HTML syntax

may result in name collisions and is generally disparaged by W3C practices

* use object

doesn't implement HTML{Video,Audio}Element semantics

* use JS parameters to non-standard JS interfaces

requires introduction of non-standard JS constructors, e.g., Audio(src,params), Video(src,params); forces procedural only expression, precluding declarative representation;

i work with a number of standards/specifications organizations that need compatibility for video/audio with the specification of arbitrary configuration parameters in a way that can adhere to current HTML5 languages, both HTML and XHTML syntaxes; these other organizations intend to define profile(s) of HTML5 and *will* define certain standard uses of such parameters, making them non-vendor dependent;

at this point, I think I've made my case clearly and repeatedly, so it won't be fruitful to comment further unless a new alternative is offered or the proposed solution is accepted;

G.
Comment 28 Glenn Adams 2011-07-27 14:15:59 UTC
(In reply to comment #26)
> (In reply to comment #24)
> > Regarding actual implementations of DRM support in browsers, there is more than
> > one browser that supports DRM of video/audio content, and which AT THE CURRENT
> > TIME makes use of the param child on object to communicate DRM parameters.
> 
> What browsers are those?

I am referring to browsers currently deployed on Televisions, Set-Top Boxes, and Mobile Devices, particularly those that participate in the playback and sharing of DRM controlled video or audio content. There are a variety of standards/specifications that apply to such devices, such as those defined by DLNA and other industry associations.

G.
Comment 29 Bob Lund 2011-07-27 15:47:33 UTC
(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #19)
> > > (In reply to comment #18)
> > > > I would like to point out that there is an existing need to pass DRM parameters
> > > > to a user agent that supports that DRM. This in no way extends the
> > > > functionality of the video API but instead conveys information to the user
> > > > agent that it needs to fetch and decode the media. <param> would provide a way
> > > > to do this. data- would also work if the restriction that Glenn cited were
> > > > removed; is that a possible path.
> > > > 
> > > > Bob Lund
> > > 
> > > Since browsers don't support DRM, you will need to provide a browser plugin to
> > > interpret the DRM parameters, no matter in which way you put them into the HTML
> > > page.
> > 
> > I guess you're referring to some of the current more popular browsers. In fact,
> > there is an activity underway defining requirements for an HTML5 user agent
> > that supports a specific DRM in a widespread, but specialized application. In
> > this case, the need to pass DRM related info exists. Aside from this specific
> > requirement to be able to convey DRM specific information acted on by the user
> > agent the video element can be used as is.
> 
> 
> I am talking about User Agents that implement the HTML5 specification in a
> cross-UA-compatible way as defined by the W3C. Are you are talking about an
> application that supports the HTML5 specification and other extra
> specifications?

Yes, I am talking about a user agent that implements the HTML5 specification and other media format specifications which are defined independent of HTML5.Today, popular user agents support different audio and video codecs. Support for media types is orthogonal to conformance to the HTML5 specification.


> That then goes beyond being a HTML5 UA and would not be
> compatible with HTML5 UAs for that extra functionality (unless used with
> plugins).

I disagree. HTML5 does not specify any audio/media formats.
 
> This is be a move towards proprietary extensions that only work in
> specific browsers

I fail to see how this goes beyond the situation as it exists today. I can author Web content that attempts to play a video of a media type supported by HTML5 UA implementation 'A' and not supported in 'B'. This page only works in specific browsers but no one is claiming this is a proprietary extension.

I think what this bug is proposing, and what I see a need for, is an HTML5 specified way to pass arbitrary media specific information to a UA implementation of the video element.

> and thus doesn't help to retain the Web as an interoperable
> platform. Why not add such specifications directly to HTML5 and bring it to the
> whole Web?
Comment 30 Glenn Adams 2011-07-27 17:26:34 UTC
(In reply to comment #27)
> * use object
> 
> doesn't implement HTML{Video,Audio}Element semantics

@sylvia

I should probably add that if video/audio are not expanded to include param as a child, then content authors (and external HTML5 profile specs) will likely end up using object for this purpose, in which case they will lose the accessibility support brought by timed text track support.

As a consequence, by arguing that we should use object, you are effectively reducing accessibility. I doubt if that's what you desire, but that will be a practical effect of your position.

G.
Comment 31 Silvia Pfeiffer 2011-07-27 22:34:18 UTC
(In reply to comment #27)
> (In reply to comment #25)
> 
> you have failed to offer a viable alternative to this proposal, all you have
> offered either doesn't work or violates some prohibition or convention; just to
> review, you have said:
> 
> * use data-*
> * use non-standard attributes in HTML syntax
> * use object
> * use JS parameters to non-standard JS interfaces


No, I have pointed to http://dev.w3.org/html5/spec/Overview.html#extensibility  which tells you how to extend in a standard way. You're trying to introduce another means of extensibility which is simply not necessary. http://dev.w3.org/html5/spec/Overview.html#extensibility in particular mentions that you can do proprietary attributes by using "x-*" named attributes. So, why don't you just use "x-param" if that's what you need?

Incidentally, anything that is just implemented and implementable by a subpart of browsers is proprietary. The kind of DRM schemes that you are thinking about probably rely on having closed source code and therefore cannot be implemented for example in Firefox. Thus, it's proprietary.
Comment 32 Henri Sivonen 2011-07-28 09:35:17 UTC
(In reply to comment #0)
> <audio>
>   <source src="audio.mp3">
>     <param name="dlna-res-protocolInfo" value="rtsp-rtp-udp:*:audio/mpeg:*">
>   </source>
>   <source src="audio.mp3">
>     <param name="dlna-res-protocolInfo"
> value="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3">
>   </source>
> </audio>

Why isn't this written as 
<audio>
  <source src="rtsp://something/audio.mp3">
  <source src="http://something/audio.mp3">
</audio>
?

(In reply to comment #28)
> (In reply to comment #26)
> > (In reply to comment #24)
> > > Regarding actual implementations of DRM support in browsers, there is more than
> > > one browser that supports DRM of video/audio content, and which AT THE CURRENT
> > > TIME makes use of the param child on object to communicate DRM parameters.
> > 
> > What browsers are those?
> 
> I am referring to browsers currently deployed on Televisions, Set-Top Boxes,
> and Mobile Devices, particularly those that participate in the playback and
> sharing of DRM controlled video or audio content. There are a variety of
> standards/specifications that apply to such devices, such as those defined by
> DLNA and other industry associations.

I meant the names of the browsers.

Why does your DRM scheme require parameters to be supplied alongside the DRM-obfuscated file? That is, why isn't it sufficient to treat the DRM wrapper as a special kind of file format? Like this:
<audio>
  <source src="audio.drm" type="audio/industry-association-drm-wrapper">
</audio>

Anyway HTML5 is trying to be a spec for the Web--a royalty-free system where multiple vendors can implement clients without asking permission from a DRM proprietor. While it's possible to reuse Web specs in closed systems, I think we shouldn't design HTML5 for closed systems, since that's a distraction that takes attention and focus away from making the Web better. That is, I think we shouldn't spend time adding closed system-motivated features.

More concretely, I don't want to disrupt the parsing of <source> (a void element--for better or worse--in shipped Web browsers) in order to cater to closed-system use cases.
Comment 33 Silvia Pfeiffer 2011-07-28 12:09:13 UTC
(In reply to comment #32)
> (In reply to comment #0)
> > <audio>
> >   <source src="audio.mp3">
> >     <param name="dlna-res-protocolInfo" value="rtsp-rtp-udp:*:audio/mpeg:*">
> >   </source>
> >   <source src="audio.mp3">
> >     <param name="dlna-res-protocolInfo"
> > value="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3">
> >   </source>
> > </audio>
> 
> Why isn't this written as 
> <audio>
>   <source src="rtsp://something/audio.mp3">
>   <source src="http://something/audio.mp3">
> </audio>
> ?
> 
> (In reply to comment #28)
> > (In reply to comment #26)
> > > (In reply to comment #24)
> > > > Regarding actual implementations of DRM support in browsers, there is more than
> > > > one browser that supports DRM of video/audio content, and which AT THE CURRENT
> > > > TIME makes use of the param child on object to communicate DRM parameters.
> > > 
> > > What browsers are those?
> > 
> > I am referring to browsers currently deployed on Televisions, Set-Top Boxes,
> > and Mobile Devices, particularly those that participate in the playback and
> > sharing of DRM controlled video or audio content. There are a variety of
> > standards/specifications that apply to such devices, such as those defined by
> > DLNA and other industry associations.
> 
> I meant the names of the browsers.
> 
> Why does your DRM scheme require parameters to be supplied alongside the
> DRM-obfuscated file? That is, why isn't it sufficient to treat the DRM wrapper
> as a special kind of file format? Like this:
> <audio>
>   <source src="audio.drm" type="audio/industry-association-drm-wrapper">
> </audio>
> 
> Anyway HTML5 is trying to be a spec for the Web--a royalty-free system where
> multiple vendors can implement clients without asking permission from a DRM
> proprietor. While it's possible to reuse Web specs in closed systems, I think
> we shouldn't design HTML5 for closed systems, since that's a distraction that
> takes attention and focus away from making the Web better. That is, I think we
> shouldn't spend time adding closed system-motivated features.
> 
> More concretely, I don't want to disrupt the parsing of <source> (a void
> element--for better or worse--in shipped Web browsers) in order to cater to
> closed-system use cases.



I actually read this whole thread as a request for an attribute and not an element. I think it can be done better with an attribute without destroying the parsing of <source> as it is now. For example, it can be done as something like:

<audio>
  <source src="audio.drm"
          x-dlna-res-protocolInfo="httpget:*:audio/mpeg:DLNA.ORG_PN=MP3">
</audio>

or

<audio>
  <source src="audio.drm"
          x-param="dlna-res-protocolInfo=httpget:*:audio/mpeg:DLNA.ORG_PN=MP3">
</audio>

In any case, I agree with Henry that we should neither destroy the parsing of <source> nor the openness of the HTML5 spec.
Comment 34 Glenn Adams 2011-07-28 14:01:45 UTC
(In reply to comment #31)
> (In reply to comment #27)
> > (In reply to comment #25)
> > 
> > you have failed to offer a viable alternative to this proposal, all you have
> > offered either doesn't work or violates some prohibition or convention; just to
> > review, you have said:
> > 
> > * use data-*
> > * use non-standard attributes in HTML syntax
> > * use object
> > * use JS parameters to non-standard JS interfaces
> 
> 
> No, I have pointed to http://dev.w3.org/html5/spec/Overview.html#extensibility 
> which tells you how to extend in a standard way. You're trying to introduce
> another means of extensibility which is simply not necessary.
> http://dev.w3.org/html5/spec/Overview.html#extensibility in particular mentions
> that you can do proprietary attributes by using "x-*" named attributes. So, why
> don't you just use "x-param" if that's what you need?

Because (1) we would need:

x-param-1
x-param-2
x-param-3
...
x-param-n

where n increases over time.

Because (2) this would introduce a disparity between HTML and XHTML syntaxes, and would require:

foo:x-param-1
foo:x-param-2
foo:x-param-3
...
foo:x-param-n

for XHTML, and who would own "foo"?

Because (3) this method may require modifying a UA for every new x-param-* added, instead of having a generic mechanism like <param> which can be collected by the UA parser (for video/audio) and passed a collection to the video/audio component/plugin as a single entity irrespective of which parameters are present.

Because (4) use of x-* attributes REDUCES interoperability and partitions content and implementations.

> Incidentally, anything that is just implemented and implementable by a subpart
> of browsers is proprietary. The kind of DRM schemes that you are thinking about
> probably rely on having closed source code and therefore cannot be implemented
> for example in Firefox. Thus, it's proprietary.

In that case, every browser is "proprietary" by your definition, since every browser implements a different subpart of HTML5 and related specs.

Firefox supports a plugin architecture that will undoubtedly be used for video/audio. As such, it does not necessarily include or ship with DRM enabled plugins from Mozilla. But that does not prevent such plugins from supporting DRM today using object.

Why should the change from object from video/audio cause the param mechanism to be removed?

Why should authors have to choose between using (1) object plus param to obtain compatibility with current practice (including) DRM and (2) video/audio minus param to obtain the new functionality of the latter while losing the functionality of the former.

G.
Comment 35 Glenn Adams 2011-07-28 14:55:45 UTC
(In reply to comment #32)
> (In reply to comment #0)
> > <audio>
> >   <source src="audio.mp3">
> >     <param name="dlna-res-protocolInfo" value="rtsp-rtp-udp:*:audio/mpeg:*">
> >   </source>
> >   <source src="audio.mp3">
> >     <param name="dlna-res-protocolInfo"
> > value="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3">
> >   </source>
> > </audio>
> 
> Why isn't this written as 
> <audio>
>   <source src="rtsp://something/audio.mp3">
>   <source src="http://something/audio.mp3">
> </audio>
> ?

Because there are additional protocol parameters that are needed beyond simply the scheme component of the URL.

The alternative is to standardize the encoding of additional protocol parameters as part of the query component of the URL, but since such parameters are intended to be used by the UA and not necessarily sent to the server, the UA would have to:

* parse the URL to extract specific parameters targeted for use by the UA
* rewrite the URL's query part to remove the UA targeted parameters

This approach would introduce more complexity and risk than a separate <param> approach. For example, one risk is that a UA targeted param appearing in the query part would conflict with (i.e., use the same name as) a server targeted query parameter.
 
> (In reply to comment #28)
> > (In reply to comment #26)
> > > (In reply to comment #24)
> > > > Regarding actual implementations of DRM support in browsers, there is more than
> > > > one browser that supports DRM of video/audio content, and which AT THE CURRENT
> > > > TIME makes use of the param child on object to communicate DRM parameters.
> > > 
> > > What browsers are those?
> > 
> > I am referring to browsers currently deployed on Televisions, Set-Top Boxes,
> > and Mobile Devices, particularly those that participate in the playback and
> > sharing of DRM controlled video or audio content. There are a variety of
> > standards/specifications that apply to such devices, such as those defined by
> > DLNA and other industry associations.
> 
> I meant the names of the browsers.

Any browser that supports a silverlight or flash plugin which includes Microsoft or Adobe defined or supported DRM schemes.

Any browser that supports the Open IPTV Forum (OIPF) content protection architecture [1].

[1] http://www.openiptvforum.org/docs/Release2/V2.1/OIPF-T1-R2-Specification-Volume-7-Authentication-Content-Protection-and-Service-Protection-2_1-2011-09-21.pdf

etc.

I work with a large Consumer Electronics company that happens to support the above in various device browsers. I'm not in a position to enumerate actual products or other companies' products, but they are out there in the field. I admit these are real world needs that exist beyond the simple, non-content protected scenarios that exist in many Web interactions; however, that does not make these needs less relevant.

> Why does your DRM scheme require parameters to be supplied alongside the
> DRM-obfuscated file? That is, why isn't it sufficient to treat the DRM wrapper
> as a special kind of file format? Like this:
> <audio>
>   <source src="audio.drm" type="audio/industry-association-drm-wrapper">
> </audio>

Firstly, I am not advocating any specific DRM scheme. I am not even advocating DRM.

I only used DRM as one example of the need to allow authors to specify arbitrary parameters to be interpreted by a DRM component in a UA component or plugin.

As to your alternative above, media types and DRM are entirely orthogonal functions, and implementations of these features tend to remain orthogonal as well. Combining the two into a single artificial media type is not a realistic approach, if for no other reason, because of the combinatorics involved. Further it would be architecturally unsound.

> Anyway HTML5 is trying to be a spec for the Web--a royalty-free system where
> multiple vendors can implement clients without asking permission from a DRM
> proprietor.

Now you are descending into a discussion about the merits or appropriateness of DRM. This is entirely outside the scope of this thread.

Adding <param> as a child of video/audio or source in no way impacts the goals of the W3C to define RF technology solutions. And this still holds if the use of <param> happens to be to communicate DRM information.

> While it's possible to reuse Web specs in closed systems, I think
> we shouldn't design HTML5 for closed systems, since that's a distraction that
> takes attention and focus away from making the Web better. That is, I think we
> shouldn't spend time adding closed system-motivated features.

Actually, by not supporting <param>, you are effectively advocating a closed system, where the currently defined video/audio attributes define the limit of that system. In the case of object, and as video/audio is currently supported in the field via object, the system (of parameter configuration data) is open. It should remain so for video/audio elements as well.

In any case, where would I18N and A11Y be if generic solutions weren't sought to these problems. One can't argue that DRM support is not relevant while simultaneously advocating for I18N or A11Y support. Or at least one can't do so without hypocrisy.

> More concretely, I don't want to disrupt the parsing of <source> (a void
> element--for better or worse--in shipped Web browsers) in order to cater to
> closed-system use cases.

param is already parsed in object; no shipped browser supports all of HTML5 and related specs; browsers are currently being modified to implement many HTML5 features; this comment about 'disruption' is entirely irrelevant at this stage of deployment

I may add that HTML5 is just in its first LC, with a strong probability that more LCs will occur BEFORE a call for implementation in a CR. This is the time when implementation experience and change occurs, so please don't pretend that HTML5 is locked up merely because some of its features have been experimentally deployed.

This bug report represents a requirement for a consistent, standardized solution for specifying arbitrary parameter data on video/audio elements that is targeted to the UA (or a plugin used by the UA). The motivation, use, standardization status, and proprietariness of such parameters is outside the scope of the need for a standardized mechanism used to specify such arbitrary parameters. The fact that HTML5 and related specs already incorporates such mechanisms in various contexts (enumerated previously) shows there is good cause and sets a precedent for such functionality. As a consequence, it is disingenuous to argue against this functionality in general terms unless you are also advocating the removal of the existing mechanisms.

G.
Comment 36 Glenn Adams 2011-07-29 00:17:25 UTC
(In reply to comment #33)
> (In reply to comment #32)
> > (In reply to comment #0)
> > > <audio>
> > >   <source src="audio.mp3">
> > >     <param name="dlna-res-protocolInfo" value="rtsp-rtp-udp:*:audio/mpeg:*">
> > >   </source>
> > >   <source src="audio.mp3">
> > >     <param name="dlna-res-protocolInfo"
> > > value="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3">
> > >   </source>
> > > </audio>
> > 
> > Why isn't this written as 
> > <audio>
> >   <source src="rtsp://something/audio.mp3">
> >   <source src="http://something/audio.mp3">
> > </audio>
> > ?
> > 
> > (In reply to comment #28)
> > > (In reply to comment #26)
> > > > (In reply to comment #24)
> > > > > Regarding actual implementations of DRM support in browsers, there is more than
> > > > > one browser that supports DRM of video/audio content, and which AT THE CURRENT
> > > > > TIME makes use of the param child on object to communicate DRM parameters.
> > > > 
> > > > What browsers are those?
> > > 
> > > I am referring to browsers currently deployed on Televisions, Set-Top Boxes,
> > > and Mobile Devices, particularly those that participate in the playback and
> > > sharing of DRM controlled video or audio content. There are a variety of
> > > standards/specifications that apply to such devices, such as those defined by
> > > DLNA and other industry associations.
> > 
> > I meant the names of the browsers.
> > 
> > Why does your DRM scheme require parameters to be supplied alongside the
> > DRM-obfuscated file? That is, why isn't it sufficient to treat the DRM wrapper
> > as a special kind of file format? Like this:
> > <audio>
> >   <source src="audio.drm" type="audio/industry-association-drm-wrapper">
> > </audio>
> > 
> > Anyway HTML5 is trying to be a spec for the Web--a royalty-free system where
> > multiple vendors can implement clients without asking permission from a DRM
> > proprietor. While it's possible to reuse Web specs in closed systems, I think
> > we shouldn't design HTML5 for closed systems, since that's a distraction that
> > takes attention and focus away from making the Web better. That is, I think we
> > shouldn't spend time adding closed system-motivated features.
> > 
> > More concretely, I don't want to disrupt the parsing of <source> (a void
> > element--for better or worse--in shipped Web browsers) in order to cater to
> > closed-system use cases.
> 
> 
> 
> I actually read this whole thread as a request for an attribute and not an
> element. I think it can be done better with an attribute without destroying the
> parsing of <source> as it is now. For example, it can be done as something
> like:

Absolutely not. I am not requesting an attribute.

> <audio>
>   <source src="audio.drm"
>           x-dlna-res-protocolInfo="httpget:*:audio/mpeg:DLNA.ORG_PN=MP3">
> </audio>
> 
> or
> 
> <audio>
>   <source src="audio.drm"
>           x-param="dlna-res-protocolInfo=httpget:*:audio/mpeg:DLNA.ORG_PN=MP3">
> </audio>

Both of these entail use of a non-standard mechanism for specifying additional parameters. If object (and other facilities) have a standard mechanism for specifying parameters, then video/audio should as well. Otherwise you should be arguing for the removal of param from object, for the removal of features argument from Window.open(), etc.

> In any case, I agree with Henry that we should neither destroy the parsing of
> <source> nor the openness of the HTML5 spec.

'destroy parsing'? what are you talking about? We are talking about a spec in the early period of its implementation. There will be *many* technical changes made before HTML5 and its relevant specs are final. Your presumption that there should be no technical change at this early stage (before the first LC is even finished) is not realistic.

'destroy openness'? really? give me a break...

G.
Comment 37 Silvia Pfeiffer 2011-07-29 02:46:17 UTC
(In reply to comment #34)
> (In reply to comment #31)
> > (In reply to comment #27)
> > > (In reply to comment #25)
> > > 
> > > you have failed to offer a viable alternative to this proposal, all you have
> > > offered either doesn't work or violates some prohibition or convention; just to
> > > review, you have said:
> > > 
> > > * use data-*
> > > * use non-standard attributes in HTML syntax
> > > * use object
> > > * use JS parameters to non-standard JS interfaces
> > 
> > 
> > No, I have pointed to http://dev.w3.org/html5/spec/Overview.html#extensibility 
> > which tells you how to extend in a standard way. You're trying to introduce
> > another means of extensibility which is simply not necessary.
> > http://dev.w3.org/html5/spec/Overview.html#extensibility in particular mentions
> > that you can do proprietary attributes by using "x-*" named attributes. So, why
> > don't you just use "x-param" if that's what you need?
> 
> Because (1) we would need:
> 
> x-param-1
> x-param-2
> x-param-3
> ...
> x-param-n
> 
> where n increases over time.


I think that's a completely adequate approach and most appropriate for standardisation. First you determine there is a need for a specific attribute (parameter), so you start using it and it gets implemented in a browser. Then that parameter becomes more relevant to other browsers, too. So, eventually it is adopted as a standard for the media elements and loses the "x-". That's perfectly do-able and scales with time.



> Because (2) this would introduce a disparity between HTML and XHTML syntaxes,
> and would require:
> 
> foo:x-param-1
> foo:x-param-2
> foo:x-param-3
> ...
> foo:x-param-n
> 
> for XHTML, and who would own "foo"?


You said that the idea is to have the params in use be standardised by other entities/organisations so they can provide parameters that are useful to their needs. It would, obviously, be that organisation then that chooses the namespace.


> Because (3) this method may require modifying a UA for every new x-param-*
> added, instead of having a generic mechanism like <param> which can be
> collected by the UA parser (for video/audio) and passed a collection to the
> video/audio component/plugin as a single entity irrespective of which
> parameters are present.

Every new param has to result in new code in either a browser or a plugin. So, I don't see a problem with having a new x-param-* introduced for it either. Also, if you really don't want that, you can always choose the second way that I proposed: x-param="yourfavoriteparameter=paramvalue" or something similar. The value of the parameter is totally up to the application to choose.


> Because (4) use of x-* attributes REDUCES interoperability and partitions
> content and implementations.


So do the <param> elements. How do you suggest making sure that the parameters stay interoperable between different browsers and plugins?


 
> > Incidentally, anything that is just implemented and implementable by a subpart
> > of browsers is proprietary. The kind of DRM schemes that you are thinking about
> > probably rely on having closed source code and therefore cannot be implemented
> > for example in Firefox. Thus, it's proprietary.
> 
> In that case, every browser is "proprietary" by your definition, since every
> browser implements a different subpart of HTML5 and related specs.


There's a difference between features that have not been implemented yet by all browsers, but are part of a specification, and features that are never meant to be implemented by all browsers.


> Firefox supports a plugin architecture that will undoubtedly be used for
> video/audio. As such, it does not necessarily include or ship with DRM enabled
> plugins from Mozilla. But that does not prevent such plugins from supporting
> DRM today using object.


Yup. Plugins are your solution, as I keep saying.


> Why should the change from object from video/audio cause the param mechanism to
> be removed?

Because param is for a communication between the Web page and plugins. The video and audio element are not designed to be used by plugins. They are instead designed to be used by specific resource types.


> Why should authors have to choose between using (1) object plus param to obtain
> compatibility with current practice (including) DRM and (2) video/audio minus
> param to obtain the new functionality of the latter while losing the
> functionality of the former.

So, you are suggesting that the <video> and <audio> elements not be interpreted by the browser, but by a plugin? I fail to see how you want to communicate from a <param> element in the <video> or <audio> element to a plugin that has not been placed into the Web page through <object> or <embed>. Can you explain?
Comment 38 Glenn Adams 2011-07-29 03:18:19 UTC
(In reply to comment #37)
> (In reply to comment #34)
> > (In reply to comment #31)
> > > (In reply to comment #27)
> > > > (In reply to comment #25)
> > > > 
> > > > you have failed to offer a viable alternative to this proposal, all you have
> > > > offered either doesn't work or violates some prohibition or convention; just to
> > > > review, you have said:
> > > > 
> > > > * use data-*
> > > > * use non-standard attributes in HTML syntax
> > > > * use object
> > > > * use JS parameters to non-standard JS interfaces
> > > 
> > > 
> > > No, I have pointed to http://dev.w3.org/html5/spec/Overview.html#extensibility 
> > > which tells you how to extend in a standard way. You're trying to introduce
> > > another means of extensibility which is simply not necessary.
> > > http://dev.w3.org/html5/spec/Overview.html#extensibility in particular mentions
> > > that you can do proprietary attributes by using "x-*" named attributes. So, why
> > > don't you just use "x-param" if that's what you need?
> > 
> > Because (1) we would need:
> > 
> > x-param-1
> > x-param-2
> > x-param-3
> > ...
> > x-param-n
> > 
> > where n increases over time.
> 
> 
> I think that's a completely adequate approach and most appropriate for
> standardisation. First you determine there is a need for a specific attribute
> (parameter), so you start using it and it gets implemented in a browser. Then
> that parameter becomes more relevant to other browsers, too. So, eventually it
> is adopted as a standard for the media elements and loses the "x-". That's
> perfectly do-able and scales with time.
> 
> 
> 
> > Because (2) this would introduce a disparity between HTML and XHTML syntaxes,
> > and would require:
> > 
> > foo:x-param-1
> > foo:x-param-2
> > foo:x-param-3
> > ...
> > foo:x-param-n
> > 
> > for XHTML, and who would own "foo"?
> 
> 
> You said that the idea is to have the params in use be standardised by other
> entities/organisations so they can provide parameters that are useful to their
> needs. It would, obviously, be that organisation then that chooses the
> namespace.
> 
> 
> > Because (3) this method may require modifying a UA for every new x-param-*
> > added, instead of having a generic mechanism like <param> which can be
> > collected by the UA parser (for video/audio) and passed a collection to the
> > video/audio component/plugin as a single entity irrespective of which
> > parameters are present.
> 
> Every new param has to result in new code in either a browser or a plugin. So,
> I don't see a problem with having a new x-param-* introduced for it either.
> Also, if you really don't want that, you can always choose the second way that
> I proposed: x-param="yourfavoriteparameter=paramvalue" or something similar.
> The value of the parameter is totally up to the application to choose.
> 
> 
> > Because (4) use of x-* attributes REDUCES interoperability and partitions
> > content and implementations.
> 
> 
> So do the <param> elements. How do you suggest making sure that the parameters
> stay interoperable between different browsers and plugins?
> 
> 
> 
> > > Incidentally, anything that is just implemented and implementable by a subpart
> > > of browsers is proprietary. The kind of DRM schemes that you are thinking about
> > > probably rely on having closed source code and therefore cannot be implemented
> > > for example in Firefox. Thus, it's proprietary.
> > 
> > In that case, every browser is "proprietary" by your definition, since every
> > browser implements a different subpart of HTML5 and related specs.
> 
> 
> There's a difference between features that have not been implemented yet by all
> browsers, but are part of a specification, and features that are never meant to
> be implemented by all browsers.
> 
> 
> > Firefox supports a plugin architecture that will undoubtedly be used for
> > video/audio. As such, it does not necessarily include or ship with DRM enabled
> > plugins from Mozilla. But that does not prevent such plugins from supporting
> > DRM today using object.
> 
> 
> Yup. Plugins are your solution, as I keep saying.
> 
> 
> > Why should the change from object from video/audio cause the param mechanism to
> > be removed?
> 
> Because param is for a communication between the Web page and plugins. The
> video and audio element are not designed to be used by plugins. They are
> instead designed to be used by specific resource types.
> 
> 
> > Why should authors have to choose between using (1) object plus param to obtain
> > compatibility with current practice (including) DRM and (2) video/audio minus
> > param to obtain the new functionality of the latter while losing the
> > functionality of the former.
> 
> So, you are suggesting that the <video> and <audio> elements not be interpreted
> by the browser, but by a plugin? I fail to see how you want to communicate from
> a <param> element in the <video> or <audio> element to a plugin that has not
> been placed into the Web page through <object> or <embed>. Can you explain?

yes, i could explain, but i perceive it would do no good since you don't seem to grasp the notion of abstraction layers;

i appreciate your input, but now I'm more interested in hearing from other parties rather than continuing an apparently fruitless debate with you as a sole correspondent;

respectfully, glenn
Comment 39 Henri Sivonen 2011-07-29 14:08:22 UTC
(In reply to comment #35)
> (In reply to comment #32)
> > Why isn't this written as 
> > <audio>
> >   <source src="rtsp://something/audio.mp3">
> >   <source src="http://something/audio.mp3">
> > </audio>
> > ?
> 
> Because there are additional protocol parameters that are needed beyond simply
> the scheme component of the URL.
> 
> The alternative is to standardize the encoding of additional protocol
> parameters as part of the query component of the URL, but since such parameters
> are intended to be used by the UA and not necessarily sent to the server, the
> UA would have to:
> 
> * parse the URL to extract specific parameters targeted for use by the UA
> * rewrite the URL's query part to remove the UA targeted parameters

UA-targeted stuff in the URL belongs in the fragment part--not the query part.

> This approach would introduce more complexity and risk than a separate <param>
> approach. For example, one risk is that a UA targeted param appearing in the
> query part would conflict with (i.e., use the same name as) a server targeted
> query parameter.

audio/industry-consortium-drm-wrapper would own the semantics of its fragment ids, though.

> > (In reply to comment #28)
> > > (In reply to comment #26)
> > > > (In reply to comment #24)
> > > > > Regarding actual implementations of DRM support in browsers, there is more than
> > > > > one browser that supports DRM of video/audio content, and which AT THE CURRENT
> > > > > TIME makes use of the param child on object to communicate DRM parameters.
> > > > 
> > > > What browsers are those?
> > > 
> > > I am referring to browsers currently deployed on Televisions, Set-Top Boxes,
> > > and Mobile Devices, particularly those that participate in the playback and
> > > sharing of DRM controlled video or audio content. There are a variety of
> > > standards/specifications that apply to such devices, such as those defined by
> > > DLNA and other industry associations.
> > 
> > I meant the names of the browsers.
> 
> Any browser that supports a silverlight or flash plugin which includes
> Microsoft or Adobe defined or supported DRM schemes.

Supporting plug-ins doesn't have any effect on DRM in <audio> or <video>.

> Any browser that supports the Open IPTV Forum (OIPF) content protection
> architecture [1].

I suppose I don't need to know concretely what products implement the spec you cite, but I have to say that allegations of products doing something appear less convincing if the person alleging product behavior consistently avoids naming concrete products.

> I work with a large Consumer Electronics company that happens to support the
> above in various device browsers. I'm not in a position to enumerate actual
> products or other companies' products, but they are out there in the field.

I see.

> > Why does your DRM scheme require parameters to be supplied alongside the
> > DRM-obfuscated file? That is, why isn't it sufficient to treat the DRM wrapper
> > as a special kind of file format? Like this:
> > <audio>
> >   <source src="audio.drm" type="audio/industry-association-drm-wrapper">
> > </audio>
...
> As to your alternative above, media types and DRM are entirely orthogonal
> functions, and implementations of these features tend to remain orthogonal as
> well.

From the point of view of "does this browser support this format?" it doesn't matter which part of the media container is container format proper and which part is DRM obfuscation, so as far as the HTML layer is concerned, it would be architecturally sound to treat the combination "container format foo obfuscated by method bar" as a container media type.

> > Anyway HTML5 is trying to be a spec for the Web--a royalty-free system where
> > multiple vendors can implement clients without asking permission from a DRM
> > proprietor.
> 
> Now you are descending into a discussion about the merits or appropriateness of
> DRM. This is entirely outside the scope of this thread.

You are asking for a spec change to a spec. Whether the motivation of the change is appropriate for the primary purpose of the spec is relevant to whether it makes sense to make the change. (The primary purpose of the HTML spec is to increase interoperability between general-purpose Web browsers. The primary purpose of DRM is to prevent interoperability with products whose developers aren't bound by the terms imposed by the DRM proprietor.)

> Adding <param> as a child of video/audio or source in no way impacts the goals
> of the W3C to define RF technology solutions. And this still holds if the use
> of <param> happens to be to communicate DRM information.

Adding <param> children to <source> is pretty late at this point. Unless such change is backed by strong rationale for advancing goals on the public Web browsable using general-purpose browsers, I think it doesn't make sense to make the change. So far, the change has been motivated by considerations that don't apply to the public Web browsable using general-purpose browsers.

> > While it's possible to reuse Web specs in closed systems, I think
> > we shouldn't design HTML5 for closed systems, since that's a distraction that
> > takes attention and focus away from making the Web better. That is, I think we
> > shouldn't spend time adding closed system-motivated features.
> 
> Actually, by not supporting <param>, you are effectively advocating a closed
> system, where the currently defined video/audio attributes define the limit of
> that system. In the case of object, and as video/audio is currently supported
> in the field via object, the system (of parameter configuration data) is open.
> It should remain so for video/audio elements as well.

<source x-industry-consortium-foo="bar"> and <source><param name="industry-consortium-foo" value="bar"></source> are merely syntactic transformations of each other. They are equally open/closed/proprietary/product-specific. The main difference is that <source x-industry-consortium-foo="bar"> doesn't require changes to the HTML parsing algorithm but <source><param name="industry-consortium-foo" value="bar"></source> does.

> In any case, where would I18N and A11Y be if generic solutions weren't sought
> to these problems. One can't argue that DRM support is not relevant while
> simultaneously advocating for I18N or A11Y support. Or at least one can't do so
> without hypocrisy.

Positioning DRM as analogous to i18n or a11y? Wow.

> > More concretely, I don't want to disrupt the parsing of <source> (a void
> > element--for better or worse--in shipped Web browsers) in order to cater to
> > closed-system use cases.
> 
> param is already parsed in object; no shipped browser supports all of HTML5 and
> related specs; browsers are currently being modified to implement many HTML5
> features; this comment about 'disruption' is entirely irrelevant at this stage
> of deployment

All major browsers have shipped parsers that treat <source> as a void element.

(In reply to comment #34)
> > So, why
> > don't you just use "x-param" if that's what you need?
> 
> Because (1) we would need:
> 
> x-param-1
> x-param-2
> x-param-3
> ...
> x-param-n
> 
> where n increases over time.

Why is this any more or less problematic than 
<param name="param-1>
<param name="param-2>
<param name="param-3>
...
<param name="param-n>
increasing over time?

> Because (2) this would introduce a disparity between HTML and XHTML syntaxes,
> and would require:
> 
> foo:x-param-1
> foo:x-param-2
> foo:x-param-3
> ...
> foo:x-param-n
> 
> for XHTML, and who would own "foo"?

You don't need foo: in XHTML. You can use x-param-1="..." in XHTML.

> Because (3) this method may require modifying a UA for every new x-param-*
> added, instead of having a generic mechanism like <param> which can be
> collected by the UA parser (for video/audio) and passed a collection to the
> video/audio component/plugin as a single entity irrespective of which
> parameters are present.

In UAs where <video>/<audio> is implemented by pluggable components, if we assume a mechanism that passes name-value pairs to the component, why should the situation be different depending on whether the pairs are collected from the attributes (as already done for <embed> and NPAPI) or from <param> (as already done for <object> and NPAPI)?

> Because (4) use of x-* attributes REDUCES interoperability and partitions
> content and implementations.

Why would it reduce interoperability more than <param> would? These are just syntactic alternatives?

> Firefox supports a plugin architecture that will undoubtedly be used for
> video/audio. 

Firefox very deliberately doesn't support plug-ins for <video>/<audio>.

> Why should authors have to choose between using (1) object plus param to obtain
> compatibility with current practice (including) DRM and (2) video/audio minus
> param to obtain the new functionality of the latter while losing the
> functionality of the former.

If the new functionality of <video>/<audio> manages to lure authors away from DRM, I think it's a good outcome, because DRM is inherently bad for the ability of a fully Free Software client stack to compete.
Comment 40 Henri Sivonen 2011-07-29 14:49:57 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: This bug report requests the HTML spec to provide <param name=foo value=bar> children for <source> as a mechanism for special-purpose browsers to attach name-value parameters to the <source> element. <source> element is treated as a void element in shipped versions of all the five major general-purpose browsers. Void elements can't have children, so this bug report is asking for an HTML parser change. HTML already provides a way to attach name-value pairs to an element: attributes. HTML also provides guidance on how to mint vendor-proprietary attributes: http://dev.w3.org/html5/spec/Overview.html#extensibility Therefore, the general problem of attaching proprietary name-value pairs to the <source> element is WORKSFORME and the specific solution of introducing <param> children to <source> is WONTFIX.
Comment 41 Glenn Adams 2011-07-29 16:41:21 UTC
I do not accept the proposed resolution for the following reasons:

(1) the resolution fails to address the bug, which is that video/audio elements do not support param children (while object does); the issue of whether source should also support param children is incidental as noted in the original submission;

(2) the resolution is based in part on the invalid claim that a technical change that affects parsing is not permissible because "it is treated as a void [empty] element in shipped versions of all the major general-purpose browsers"; this is entirely irrelevant, and probably not true either; note that any implementation of HTML5 as currently drafted is subject to technical changes, a consequence of the current status of the published 1st LCWD which states "Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways."

(3) the resolution assumes the bug is intended to be used "to mint vendor-proprietary attributes", which is not the case;

Unless this bug is substantially addressed, then I will continue to reopen it until it is elevated to an Issue recorded against HTML5 for resolution by the WG as a whole.

Regards,
Glenn
Comment 42 Henri Sivonen 2011-07-29 16:57:21 UTC
(In reply to comment #41)
> (1) the resolution fails to address the bug, which is that video/audio elements
> do not support param children (while object does); the issue of whether source
> should also support param children is incidental as noted in the original
> submission;

<embed> uses attributes. <object> only uses <param>, because it wasn't possible to make arbitrary attributes allowed in a DTD. We aren't using DTDs anymore, so the only reason for the <param> design to continue to exist is that object already uses <param>.

> (2) the resolution is based in part on the invalid claim that a technical
> change that affects parsing is not permissible because "it is treated as a void
> [empty] element in shipped versions of all the major general-purpose browsers";
> this is entirely irrelevant, and probably not true either

It is true and the truth is easily experimentally verifiable. (I experimentally verified it today.)

> (3) the resolution assumes the bug is intended to be used "to mint
> vendor-proprietary attributes", which is not the case;

It's intended to mint vendor-proprietary name-value pair parameters, AFAICT.
Comment 43 Glenn Adams 2011-07-29 17:58:30 UTC
(In reply to comment #42)
> (In reply to comment #41)
> > (1) the resolution fails to address the bug, which is that video/audio elements
> > do not support param children (while object does); the issue of whether source
> > should also support param children is incidental as noted in the original
> > submission;
> 
> <embed> uses attributes. <object> only uses <param>, because it wasn't possible
> to make arbitrary attributes allowed in a DTD. We aren't using DTDs anymore, so
> the only reason for the <param> design to continue to exist is that object
> already uses <param>.
> 
> > (2) the resolution is based in part on the invalid claim that a technical
> > change that affects parsing is not permissible because "it is treated as a void
> > [empty] element in shipped versions of all the major general-purpose browsers";
> > this is entirely irrelevant, and probably not true either
> 
> It is true and the truth is easily experimentally verifiable. (I experimentally
> verified it today.)

For the record, could you indicate which browsers and which versions you tested? Did you also test whether param on video/audio is processed or supported in any way by these browsers?
 
> > (3) the resolution assumes the bug is intended to be used "to mint
> > vendor-proprietary attributes", which is not the case;
> 
> It's intended to mint vendor-proprietary name-value pair parameters, AFAICT.

I have stated times that I am working with a number of standards/specifications organizations other than the W3C which define, promote, and deploy profiles of W3C specifications, including HTML. These organizations are not proprietary vendors. One of them defines standards that are widely adopted in Consumer Electronics products. The other defines guidelines and specifications that have been incorporated into or referenced by rules adopted by the US Government (FCC). Another still defines specifications adopted by device manufacturers and service providers worldwide. Examples of such specifications are CEA-2014-{A,B} (CE-HTML) [1], DLNA Guidelines 2009 [2], and OpenTV [3], e.g., sections 7.14.10 These specifications are neither vendor specific nor proprietary.

[1] http://www.ce.org/standards/listings.asp
[2] http://www.dlna.org/
[3] http://www.openiptvforum.org/docs/Release2/V2.1/OIPF-T1-R2-Specification-Volume-5-Declarative-Application-Environment-v2_1-2011-06-21.pdf

In the above referenced works, standardized profiles of HTML4 and XHTML1 define specific parameters for use with the object element. Implementations of UAs that comply with these profiles are typically implemented in devices, such as televisions, set-top boxes, mobile phone handsets, tablet devices and other products.

These organizations are now preparing profile(s) on HTML5 and wish to transition from object to video/audio in order to obtain functionality from new mechanisms defined in HTML5, such as HTML{Video,Audio}Element functionality. In order to do this, some means must be provided to express the parameters currently used with object but for use with video/audio elements based on the same (A/V) media types formerly referenced by object.

The issue of whether an implementation of one of these profiles happens to implement support for specific media types on video/audio via a built-in component or a plug-in is entirely arbitrary and a private decision of the product manufacturer. So objections made upon a distinction between plugin and browser are not relevant.

In order to remain consistent with existing implementations and plugins which *do* make use of param on object, and to facilitate the transition from object to video/audio, support of param element on video/audio is desirable. Whether param is also supported on source is a secondary issue, and should be treated as such. There are arguments to be made both for and against it.

The alternative proposed by Sylvia and yourself to make use of private x-* attributes is not acceptable because it is not a standardized syntax. In contrast, param is a standardized syntax supported by existing abstraction layers in media components and plugins. Use of param has the advantage that no change to a DTD or XML schema is required to introduce new parameters, since the name and value attributes of param are typed as xsd:string and are not enumerated values. In contrast, each addition of a parameter based on x-* requires a DTD or schema change and will in most cases requires specific alterations to a general purpose HTML5 parsers (in order to recognize specific x-* attributes as opposed to recognizing a generic set of name value pairs which are opaque to such a parser.

Your premature rejection of this bug fails to take into account the above considerations. Furthermore, the affected content authors and device browser implementers are not sufficiently represented by your personal response.

If there is a continued reluctance to substantially address this bug, then it would be best to elevate it to Issue so that the WG as a whole can establish a full consensus position based on more than a few private commenters (yourself and Sylvia).

Regards,
Glenn
Comment 44 Glenn Adams 2011-07-29 18:40:39 UTC
(In reply to comment #43)
> Examples of such specifications are CEA-2014-{A,B}
> (CE-HTML) [1], DLNA Guidelines 2009 [2]
> 
> [1] http://www.ce.org/standards/listings.asp
> [2] http://www.dlna.org/

To provide further documentation, consider the following language found in CEA-2014-A, Section 5.7.1, which is normatively referenced by DLNA Guidelines:

"[Req. 5.7.1.a] The Remote UI Client SHALL support the control of audio and video content
through the use of <object>-elements (see [5] and Annex G for a definition of the <object>-
element), whereby:

1) The “type” attribute SHALL be included to define the MIME-type used for the audio or
video profile that matches the content referred to by the value of the “data” attribute.

2) An <object>-element SHOULD contain a <param>-element dlna_res_attr which SHALL
contain the media properties attributes associated with the content resource that is
referred to by the value of the data attribute. These media properties SHALL be an XML
escaped string containing the space-separated list of attributes of one single “res”-
element, of which the format and possible values have been defined by the DLNA
guidelines [2] related to a UPnP Content Directory Service (CDS). Employing UPnP A/V
standards for the playback and control of A/V is OPTIONAL, not required.

3) An <object>-element of type video (as defined by [Req 5.7.1.b]) SHOULD contain a
<param>-element to set the aspect ratio parameter of this object. This is an initial aspect
ratio of the video content."

and

"This is an example of an <object>-tag used for including an object of type video:

<object type="video/mpeg" id="vid1" data="http://www.avsource.com/video/test.mpg">
  <param name=”dlna_res_attr“
    value=”protocolInfo=&quot;http-get:*:video/mpeg:DLNA.ORG_PN=MPEG_PS_NTSC&quot;duration=&quot;1:25:34&quot;”/>
  <param name=”aspectratio“ value=”1.33”/>
</object>

Note: a Remote UI Client SHOULD provide native support for these <object>-elements, and
is not required to support downloading of a plug-in to support these <object>-elements."

In CEA-2014-B , this is expanded as follows

"[Req. 5.7.1.f0] The Remote UI Client SHALL support the following <param>-elements as childelement
of the <object>-element used for instantiating the A/V control scripting object:

a. <param name=”aspectratio” value=”…”/> - sets the preferred aspect ratio of this
object. This is an initial aspect ratio of the video content. The value of this parameter
SHALL equal the width divided by height, rounded to a float value with two decimals, e.g.
1.78 to indicate 16:9 and 1.33 to indicate 4:3. Recommended to include this parameter as
child of the <object>-element used for A/V control scripting object.

b. <param name=”loop” value=”…”/> - sets the number of times the A/V content SHALL
be played. A/V playback SHALL be automatically restarted if the end of content is reached
and the content has not been played the number of times indicated by the loop parameter.
The value of this parameter SHALL be either:

  i. the number of times (> 0) that the content SHALL be played, OR

  ii. “infinite” if the content SHALL be looped continuously.
  If the AV Player is reinitialized (i.e. the data or type attribute has changed as per [Req.
  5.7.1.l]), the indicated loop count SHALL be automatically re-applied by the Remote UI
  Client. If the AV player is stopped or paused, and subsequently restarted, the current
  pending loop count SHALL remain in effect. If missing, the default value of the loop
  parameter SHALL be 1.

c. <param name=”autostart” value”…”/> - used for indicating whether or not the A/V
Player scripting object SHALL behave as if an initial play(1) method call was
automatically issued. If the A/V Player scripting object is reinitialized (i.e. the data or
type attribute has changed as per [Req. 5.7.1.l]), then the behavior indicated by the value
of the autostart parameter SHALL be automatically re-applied by the Remote UI Client.
The value of this parameter SHALL be “true” or “false”. If missing, the default value of the
autostart parameter SHALL be “false”.

d. <param name=”avControlMode” value=”…”/> - This parameter is used to set the
playback control mode of the A/V control scripting object. The following values SHALL be
supported:

  i. “ruicontrol”: the A/V control scripting object provides an audio/video playback
  window without any additional user-interface controls. See [Req 5.7.1.i] for more
  details.

  ii. “localcontrol”: the A/V control scripting object provides an audio/video playback 
  window which includes user-interface controls. See [Req 5.7.1.i] for more details.
  The default mode of operation (i.e. if the server did not include a “avControlMode”
  <param>-element) SHALL be “ruicontrol”.

[Req. 5.7.1.f1] The Remote UI Client MAY support the following <param>-elements as childelement
of the <object>-element used for instantiating the A/V control scripting object:

a. <param name=”dlna_res_attr” value=”…”/> - used to convey media properties that are
useful for playback and control of A/V in a DLNA/UPnP environment. The value of this
parameter SHALL contain the media properties associated with the content resource that
is referred to by the value of the “data” attribute. These media properties SHALL be an
XML escaped string containing the space-separated list of attributes of one single “res”-
element, of which the format and possible values have been defined by the DLNA
guidelines [2] related to a UPnP Content Directory Service (CDS). Employing UPnP A/V
standards for the playback and control of A/V is OPTIONAL, not required."

As can be seen, the set of "standardized" param names/values increases/changes over time in such a manner as to preclude an a priori definition of new attributes.

Again, these are NOT vendor-specific or proprietary uses of param.

G.
Comment 45 Silvia Pfeiffer 2011-07-30 10:19:42 UTC
Dear Glenn,

"A plugin is, quite simply, a third party library that “plugs in” to the browser that can be embedded inside a web page using an <embed> tag or a <object> tag.  Many of them then draw pretty pictures or animations, though that’s not required.  Many allow you to talk to them through javascript, though that’s not required.  In short, a plugin affects only a specific page in which it is placed."
http://colonelpanic.net/2010/08/browser-plugins-vs-extensions-the-difference/

"Plugins have to either handle a mime type or be embedded into a web page.  They don’t get put there automatically. They don’t create toolbars.  They don’t affect browser menus.  They don’t know about tabs, or even about other pages in the same browser process.  They don’t make coffee, tea, or hot chocolate, though they could be written to control an external appliance to do so if you really wanted.  They don’t automatically process the content of every web page loaded."

OK, now that we know who has a problem with abstraction layers, maybe we can move back to a technical conversation about the HTML5 specification. Since I am aware that there may be a large number of people that you are communicating with about this, I will continue to try and help and ignore the attitude.

I assume the type of plugins that you may be thinking about for extending the functionality of the <video> element may not be the usual browser plugins. They may be more akin to the way in which you can gain WebM support in IE: namely through a Media Foundation component (http://tools.google.com/dlpage/webmmf). Indeed, IE, Chrome, and Opera use media frameworks to provide media resource decoding for <video> and <audio>. But even then: most of them have disabled the ability to generally support all codecs installed on a system and restrict this to a given list. More fundamentally though: Firefox does not use such a framework and instead only provides support for specific compiled-in codecs.

Thus, proposing a generalised framework for communicating video decoding and display parameters to a specialised decoder in a custom browser just isn't relevant to the majority of browsers.

Now, I think there is a more fundamental problem with your approach than the sheer mechanics of implementation: You are trying to meld the new HTML5 standard onto existing standards that have prescribed <object> for video published. That's fundamentally the wrong approach towards <video> and <audio>. Instead, you should adapt those standards to the new HTML5 specification. This requires understanding what the <audio> and <video> elements already provide and mapping the use cases that have been specified to be implemented through specific <param> values to the existing attributes of <audio> and <video>. Any remaining use cases should either also be standardised in HTML5, or use the x-* attribute extension mechanism.

To examplify what I mean, I'll give you some hints in the list that you provided below.


(In reply to comment #44)
> (In reply to comment #43)
...
> 1) The “type” attribute SHALL be included to define the MIME-type used for
> the audio or
> video profile that matches the content referred to by the value of the
> “data” attribute.


The mime type of the video or audio element's resource can be provided through the @type attribute of a <source> element like this:

<video>
  <source src="yourfile.ext" type="mime/type">
</video>


> 2) An <object>-element SHOULD contain a <param>-element dlna_res_attr which
> SHALL
> contain the media properties attributes associated with the content resource
> that is
> referred to by the value of the data attribute.
...

Not quite sure what this is and why any more than the URL would be required to specify the media properties, but this seems a clear example for something that is specific to a particular application domain and not the general Web. So, a custom attribute is probably useful. Something like this:

<video>
  <source src="yourfile.ext" type="mime/type" x-dlna-res-attr="protocolInfo=rtsp-rtp-udp:*:audio/mpeg:*">
</video>


> 3) An <object>-element of type video (as defined by [Req 5.7.1.b]) SHOULD
> contain a
> <param>-element to set the aspect ratio parameter of this object. This is an
> initial aspect
> ratio of the video content."
...


The aspect ratio of HTML5 video will always be retained and end up in pillarboxed or letterboxed video if the video viewport doesn't match. For changing this, we have CSS, in particular the object-fit and object-position styles that help adapt positioning and aspect ration changes within the video viewport. This is a more practical way of dealing with aspect ratio than trying to tell a decoder what aspect ratio a video should be decoded to.


> b. <param name=”loop” value=”…”/> - sets the number of times the A/V
> content SHALL
> be played. A/V playback SHALL be automatically restarted if the end of content
> is reached
> and the content has not been played the number of times indicated by the loop
> parameter.
> The value of this parameter SHALL be either:
> 
>   i. the number of times (> 0) that the content SHALL be played, OR
> 
>   ii. “infinite” if the content SHALL be looped continuously.
>   If the AV Player is reinitialized (i.e. the data or type attribute has
> changed as per [Req.
>   5.7.1.l]), the indicated loop count SHALL be automatically re-applied by the
> Remote UI
>   Client. If the AV player is stopped or paused, and subsequently restarted,
> the current
>   pending loop count SHALL remain in effect. If missing, the default value of
> the loop
>   parameter SHALL be 1.


<video> and <audio> have a @loop attribute. You could, however, make a case for it to have the values that your param is proposing rather than being a boolean attribute if you saw a need for it. 


> c. <param name=”autostart” value”…”/> - used for indicating whether
> or not the A/V
> Player scripting object SHALL behave as if an initial play(1) method call was
> automatically issued.

<video> and <audio> have the @autoplay attribute for this.

...
> d. <param name=”avControlMode” value=”…”/> - This parameter is used
> to set the
> playback control mode of the A/V control scripting object.

<video> and <audio> have the @controls attribute for this.

...

 
> As can be seen, the set of "standardized" param names/values increases/changes
> over time in such a manner as to preclude an a priori definition of new
> attributes.

No, you haven't proven this at all. Most of the parameters that you are asking for already exist. And for others we have the x-* extensions. I have only seen one such extension need above which does not constitute an "explosion of attributes".

I would suggest that a detailed analysis of the needs that your suggested <param> element would satisfy is the right way to progress. You may find - as above - that most needs are already satisfied by existing attributes.
Comment 46 Glenn Adams 2011-07-30 13:31:23 UTC
Sylvia,

You persist in wanting to analyze specific parameters and their motivation, functionality, etc. I have no interest in doing that. I am just offering additional, published evidence of standardized uses of <param> and don't care what information they express. This is what I mean by an abstraction layer; on the other hand, your continued focus on the specific parameters in my numerous examples reinforces in my mind that you do not consider or understand the value of the abstraction layer provided by <param>. Or perhaps you have another agenda here? Perhaps your interest in WebM (which you bring up below) is driving your comments to find ways to exclude other formats or the existing architectures that support those other formats? Perhaps you wish to argue that only those parameters appropriate to WebM should be supported by video/audio, while ignoring the parametric needs of other formats? Perhaps you wish to argue that the specific implementation and policy choices adopted by Mozilla should hold universally? As for me, I support WebM but I also support H.264 and any other format a content provider wishes to use or a UA or component or framework or plugin implementer wishes support. I don't know all the parameters needed by these formats. That is a side effect of the fact the set of format is not fixed, and therefore, the set of parameters is not fixed. I do know that param exists and that object works with many formats and uses the param abstraction to accomplish this in deployed content and browsers. I want video/audio to work with all formats and implementation architectures. I don't care whether a browser implements its support for a format internally or via a media framework or via 3rd party plugins using a plugin architecture. I don't distinguish between a plugin architecture and a media framework for the purpose of this discussion. That is an implementation detail outside the scope of HTML5. Another "abstraction layer" that you don't appear to recognize. I don't like x-* attributes. They are *always* vendor specific. They are not standard. Their use has been historically deprecated in by the W3C. They require constant changes in schemas and DTDs or remain unvalidated. I have shown evidence of non-vendor specific, standardized param uses, and I believe it would be wrong to force them to be expressed using x-* attributes. If I have to choose among existing alternatives without having param, then I would choose data-* attributes and ignore the prohibition in HTML5 against such use in a UA specific fashion.

Yes, I am talking to a variety of people about this issue, and yes, there is support not only for the problem statement but the proposed solution. I intend to escalate this as needed to obtain resolution by determining a consensus in this larger community.

G.

(In reply to comment #45)
> Dear Glenn,
> 
> "A plugin is, quite simply, a third party library that “plugs in” to the
> browser that can be embedded inside a web page using an <embed> tag or a
> <object> tag.  Many of them then draw pretty pictures or animations, though
> that’s not required.  Many allow you to talk to them through javascript,
> though that’s not required.  In short, a plugin affects only a specific page
> in which it is placed."
> http://colonelpanic.net/2010/08/browser-plugins-vs-extensions-the-difference/
> 
> "Plugins have to either handle a mime type or be embedded into a web page. 
> They don’t get put there automatically. They don’t create toolbars.  They
> don’t affect browser menus.  They don’t know about tabs, or even about
> other pages in the same browser process.  They don’t make coffee, tea, or hot
> chocolate, though they could be written to control an external appliance to do
> so if you really wanted.  They don’t automatically process the content of
> every web page loaded."
> 
> OK, now that we know who has a problem with abstraction layers, maybe we can
> move back to a technical conversation about the HTML5 specification. Since I am
> aware that there may be a large number of people that you are communicating
> with about this, I will continue to try and help and ignore the attitude.
> 
> I assume the type of plugins that you may be thinking about for extending the
> functionality of the <video> element may not be the usual browser plugins. They
> may be more akin to the way in which you can gain WebM support in IE: namely
> through a Media Foundation component (http://tools.google.com/dlpage/webmmf).
> Indeed, IE, Chrome, and Opera use media frameworks to provide media resource
> decoding for <video> and <audio>. But even then: most of them have disabled the
> ability to generally support all codecs installed on a system and restrict this
> to a given list. More fundamentally though: Firefox does not use such a
> framework and instead only provides support for specific compiled-in codecs.
> 
> Thus, proposing a generalised framework for communicating video decoding and
> display parameters to a specialised decoder in a custom browser just isn't
> relevant to the majority of browsers.
> 
> Now, I think there is a more fundamental problem with your approach than the
> sheer mechanics of implementation: You are trying to meld the new HTML5
> standard onto existing standards that have prescribed <object> for video
> published. That's fundamentally the wrong approach towards <video> and <audio>.
> Instead, you should adapt those standards to the new HTML5 specification. This
> requires understanding what the <audio> and <video> elements already provide
> and mapping the use cases that have been specified to be implemented through
> specific <param> values to the existing attributes of <audio> and <video>. Any
> remaining use cases should either also be standardised in HTML5, or use the x-*
> attribute extension mechanism.
> 
> To examplify what I mean, I'll give you some hints in the list that you
> provided below.
> 
> 
> (In reply to comment #44)
> > (In reply to comment #43)
> ...
> > 1) The “type” attribute SHALL be included to define the MIME-type used for
> > the audio or
> > video profile that matches the content referred to by the value of the
> > “data” attribute.
> 
> 
> The mime type of the video or audio element's resource can be provided through
> the @type attribute of a <source> element like this:
> 
> <video>
>   <source src="yourfile.ext" type="mime/type">
> </video>
> 
> 
> > 2) An <object>-element SHOULD contain a <param>-element dlna_res_attr which
> > SHALL
> > contain the media properties attributes associated with the content resource
> > that is
> > referred to by the value of the data attribute.
> ...
> 
> Not quite sure what this is and why any more than the URL would be required to
> specify the media properties, but this seems a clear example for something that
> is specific to a particular application domain and not the general Web. So, a
> custom attribute is probably useful. Something like this:
> 
> <video>
>   <source src="yourfile.ext" type="mime/type"
> x-dlna-res-attr="protocolInfo=rtsp-rtp-udp:*:audio/mpeg:*">
> </video>
> 
> 
> > 3) An <object>-element of type video (as defined by [Req 5.7.1.b]) SHOULD
> > contain a
> > <param>-element to set the aspect ratio parameter of this object. This is an
> > initial aspect
> > ratio of the video content."
> ...
> 
> 
> The aspect ratio of HTML5 video will always be retained and end up in
> pillarboxed or letterboxed video if the video viewport doesn't match. For
> changing this, we have CSS, in particular the object-fit and object-position
> styles that help adapt positioning and aspect ration changes within the video
> viewport. This is a more practical way of dealing with aspect ratio than trying
> to tell a decoder what aspect ratio a video should be decoded to.
> 
> 
> > b. <param name=”loop” value=”…”/> - sets the number of times the A/V
> > content SHALL
> > be played. A/V playback SHALL be automatically restarted if the end of content
> > is reached
> > and the content has not been played the number of times indicated by the loop
> > parameter.
> > The value of this parameter SHALL be either:
> > 
> >   i. the number of times (> 0) that the content SHALL be played, OR
> > 
> >   ii. “infinite” if the content SHALL be looped continuously.
> >   If the AV Player is reinitialized (i.e. the data or type attribute has
> > changed as per [Req.
> >   5.7.1.l]), the indicated loop count SHALL be automatically re-applied by the
> > Remote UI
> >   Client. If the AV player is stopped or paused, and subsequently restarted,
> > the current
> >   pending loop count SHALL remain in effect. If missing, the default value of
> > the loop
> >   parameter SHALL be 1.
> 
> 
> <video> and <audio> have a @loop attribute. You could, however, make a case for
> it to have the values that your param is proposing rather than being a boolean
> attribute if you saw a need for it. 
> 
> 
> > c. <param name=”autostart” value”…”/> - used for indicating whether
> > or not the A/V
> > Player scripting object SHALL behave as if an initial play(1) method call was
> > automatically issued.
> 
> <video> and <audio> have the @autoplay attribute for this.
> 
> ...
> > d. <param name=”avControlMode” value=”…”/> - This parameter is used
> > to set the
> > playback control mode of the A/V control scripting object.
> 
> <video> and <audio> have the @controls attribute for this.
> 
> ...
> 
> 
> > As can be seen, the set of "standardized" param names/values increases/changes
> > over time in such a manner as to preclude an a priori definition of new
> > attributes.
> 
> No, you haven't proven this at all. Most of the parameters that you are asking
> for already exist. And for others we have the x-* extensions. I have only seen
> one such extension need above which does not constitute an "explosion of
> attributes".
> 
> I would suggest that a detailed analysis of the needs that your suggested
> <param> element would satisfy is the right way to progress. You may find - as
> above - that most needs are already satisfied by existing attributes.
Comment 47 Philip Jägenstedt 2011-08-03 11:13:18 UTC
(In reply to comment #36)
> (In reply to comment #33)
> > In any case, I agree with Henry that we should neither destroy the parsing of
> > <source>
> 
> 'destroy parsing'? what are you talking about?

Deployed content uses <source> like this:

<video>
  <source src="video.mp4">
  <source src="video.webm">
</video>

The resource selection algorithm only considers child source element of <video>. If a browser changed the parsing of <source> to not be a void element, the above would be equivalent to:

<video>
  <source src="video.mp4">
    <source src="video.webm"></source>
  </source>
</video>

The second <source> element would not be considered and existing content would just not work. Changing the resource selection algorithm to consider *any* descendant <source> element would not be a good idea, as it precludes ever making spec changes like putting extra <audio> tracks inside <video>.
Comment 48 Glenn Adams 2011-08-03 13:58:45 UTC
(In reply to comment #47)
> (In reply to comment #36)
> > (In reply to comment #33)
> > > In any case, I agree with Henry that we should neither destroy the parsing of
> > > <source>
> > 
> > 'destroy parsing'? what are you talking about?
> 
> Deployed content uses <source> like this:
> 
> <video>
>   <source src="video.mp4">
>   <source src="video.webm">
> </video>
> 
> The resource selection algorithm only considers child source element of
> <video>. If a browser changed the parsing of <source> to not be a void element,
> the above would be equivalent to:
> 
> <video>
>   <source src="video.mp4">
>     <source src="video.webm"></source>
>   </source>
> </video>
> 
> The second <source> element would not be considered and existing content would
> just not work. Changing the resource selection algorithm to consider *any*
> descendant <source> element would not be a good idea, as it precludes ever
> making spec changes like putting extra <audio> tracks inside <video>.

It is not the intent of this bug report to propose nested source elements, but only to enable param as a child of video, audio, and source. So, in this sense, the HTML specific syntax processing would need to reclassify source from void to normal element type. A missing end tag for source can be implied by the following rule (to be added 8.1.2.4 Optional Tags:

"A source element's end tag may be omitted if the source element is immediately followed by another source element, or if there is no more content in the parent element."

At present, video and audio do not allow optional end tags in the HTML syntax, so end tag implication does not apply there. Also, end tag implication does not arise in the XHTML syntax of HTML5.

While the proposed change would entail a modification for HTML syntax parsing to handle source end tag implication, that should be a trivial change in the current experimental implementations of HTML5.

Finally, I would note that it may be acceptable to add param only to video and audio, and not require its support with param. As I noted in the original comments to this bug, adding param to source is a secondary, convenience mechanism that permits separating those parameters that are independent of the selected source from those parameters dependent on the selected source. Although it would be less general, not having param on source could still be accommodated through other conventions, e.g.,

Example #3 - Configure DLNA A/V Connection Manager for Audio Playback with RTP
preference over HTTP

<audio>
  <param name="source-1-dlna-res-protocol" value="rtsp-rtp-udp:*:audio/mpeg:*"/>
  <param name="source-2-dlna-res-protocol" value="http-get:*:audio/mpeg:DLNA.ORG_PN=MP3"/>
  <source src="audio.mp3">
  <source src="audio.mp3">
</audio>

However, this is clearly a more awkward way to address source dependent parameters than expressing such parameters as children param elements on source.

Regards,
Glenn
Comment 49 John Foliot 2011-08-03 20:10:48 UTC
(In reply to comment #40)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. 
> 
> Status: Rejected
> Change Description: no spec change
> Rationale: This bug report requests the HTML spec to provide <param name=foo
> value=bar> children for <source> as a mechanism for special-purpose browsers to
> attach name-value parameters to the <source> element.
> <source> element is
> treated as a void element in shipped versions of all the five major
> general-purpose browsers. Void elements can't have children, so this bug report
> is asking for an HTML parser change.


Actually, the bug stated that <audio>, <video> *and* <source> should be able to take <param> attributes. While it may be that at this time <source> cannot take a <param>, technically both <audio> and <video> could. 

In Comment 48 Glenn also notes:
"Finally, I would note that it may be acceptable to add param only to video and
audio, and not require its support with param." (Did he mean source instead of param here?)


> Therefore, the general
> problem of attaching proprietary name-value pairs to the <source> element is
> WORKSFORME

Actually, this now appears incorrect - data-* will not work here.


> and the specific solution of introducing <param> children to
> <source> is WONTFIX.

It is clear that this is an issue that is more complex than what some participants think. Given that there has been continued dialog on this topic subsequent to Henri seeking to close this bug, (and the noted possibility of negative impacts on accessibility concerns - Comment 30) I will ask that this become a Tracked Issue at the Task Force. I expect that at least one formal Change Proposal will emerge.
Comment 50 Glenn Adams 2011-08-03 20:41:24 UTC
minor correction

(In reply to comment #48)
> Finally, I would note that it may be acceptable to add param only to video and
> audio, and not require its support with param.

s/with param/with source/
Comment 51 Michael[tm] Smith 2011-08-04 05:03:14 UTC
mass-moved component to LC1
Comment 52 Henri Sivonen 2011-08-04 08:48:42 UTC
(In reply to comment #43)
> > It is true and the truth is easily experimentally verifiable. (I experimentally
> > verified it today.)
> 
> For the record, could you indicate which browsers and which versions you
> tested? 

I tested IE9's IE9 standards mode, Firefox trunk (but I know the behavior to be the same since Firefox 3.5), some version of Chrome in the 13 or 14 series (what I now have is 14.something but it might have been 13.something a few days ago; anyway, I know the behavior to have been the same since Chrome 8 and most likely since Chrome 3), Safari 5.1 (and I know the behavior has been the same earlier) and Opera 11.50 (and I know the behavior has been the same earlier).

> Did you also test whether param on video/audio is processed or
> supported in any way by these browsers?

I didn't.

> > > (3) the resolution assumes the bug is intended to be used "to mint
> > > vendor-proprietary attributes", which is not the case;
> > 
> > It's intended to mint vendor-proprietary name-value pair parameters, AFAICT.
> 
> I have stated times that I am working with a number of standards/specifications
> organizations other than the W3C which define, promote, and deploy profiles of
> W3C specifications, including HTML. These organizations are not proprietary
> vendors. 

Let's say "special-purpose" instead of "proprietary" then. (Where "special-purpose" means that the stuff isn't expected to be implemented in general-purpose implementations of HTML. If what these organizations are speccing were general-purpose features, the features should by specced in the W3C HTML spec itself.)

> In order to remain consistent with existing implementations and plugins which
> *do* make use of param on object, and to facilitate the transition from object
> to video/audio, support of param element on video/audio is desirable.

<param> exists because the group that defined HTML 4 couldn't figure out how to write a DTD for <embed>. The design that involves passing the attributes of an element to a 3rd-party software component actually came first (in Netscape 2.0)! HTML5 doesn't use DTDs anymore, so that problem is no longer there. <param> shouldn't be regarded as a positive role model or a design that merits perpetuating or emulating for any purpose other than keeping the syntax of <object> itself backwards compatible.

> The alternative proposed by Sylvia and yourself to make use of private x-*
> attributes is not acceptable because it is not a standardized syntax. In
> contrast, param is a standardized syntax supported by existing abstraction
> layers in media components and plugins.

If you have an attribute x-dlna-foo or dlna-foo or a param <param name=dlna-foo>, the syntax can be exactly as standardized or non-standardized. Whether a token is in an attribute name or in an attribute value has no bearing on how standardized the token is.

(In reply to comment #44)
> As can be seen, the set of "standardized" param names/values increases/changes
> over time in such a manner as to preclude an a priori definition of new
> attributes.

Why can't you mint more attributes over time? Why would you need to have a priori definitions for future attributes?

Would it work for you if HTML set attributes whose names begin with dlna- aside for use in DLNA specs?

(In reply to comment #49)
> > Therefore, the general
> > problem of attaching proprietary name-value pairs to the <source> element is
> > WORKSFORME
> 
> Actually, this now appears incorrect - data-* will not work here.

I didn't mean data-*. I meant x-dlna-* (or just dlna-*).
Comment 53 John Foliot 2011-09-21 00:22:32 UTC
Moving to Resolved - won't Fix (Editor's response) to then add TrackerRequest keyword
Comment 54 Sam Ruby 2011-09-21 01:49:08 UTC
(In reply to comment #53)
> Moving to Resolved - won't Fix (Editor's response) to then add TrackerRequest
> keyword

From the EDITOR'S RESPONSE "please add the TrackerRequest keyword to this bug,
and suggest title and text for the tracker issue; or you may create a tracker
issue yourself, if you are able to do so"

Does anybody want to propose title and text for the tracker issue?  Or to
create the tracker issue themselves?
Comment 55 Glenn Adams 2011-09-21 02:04:00 UTC
(In reply to comment #54)
> (In reply to comment #53)
> Does anybody want to propose title and text for the tracker issue?  Or to
> create the tracker issue themselves?

I will do so shortly.
Comment 56 Glenn Adams 2011-09-21 02:55:52 UTC
(In reply to comment #55)
> (In reply to comment #54)
> > (In reply to comment #53)
> > Does anybody want to propose title and text for the tracker issue?  Or to
> > create the tracker issue themselves?
> 
> I will do so shortly.

(In reply to comment #55)
> (In reply to comment #54)
> > (In reply to comment #53)
> > Does anybody want to propose title and text for the tracker issue?  Or to
> > create the tracker issue themselves?
> 
> I will do so shortly.

Title: {audio,video} require param child (or equivalent)

Description:

As currently defined, the audio|video elements do not define a mechanism to permit the content author to specify arbitrary parameters to the user agent to be used in transporting, decoding, rendering, and controlling the audio|video content. Prior to HTML5, this was accomplished using the object element while specifying such parameters using the param element child of object.

In order to maintain continuity and support for such pre-existing usage and to permit migration from object to the new audio|video elements, the audio|video elements should similarly support a standardized mechanism by means of which various arbitrary parameters may be communicated to the user agent.

An important use case for such feature is manifested when using audio|video elements to refer to content sourced within a UPnP or DLNA ecosystem. In the usage scenarios employed therein, a ContentDirectoryService (CDS) exposes two important pieces of information for audio|video content items:

(1) a URL that references the content on a server;
(2) an arbitrary list of {name,value} parameters encoded in the fourth field of what UPnP refers to as a 'ProtocolInfo' data structure;

In order for an HTML5 user agent to dereference and effect transport, decoding, playback, and control of such audio|video content, it is necessary to supply both the URL and this arbitrary set of parameters to the user agent, wherein the user agent itself semantically interprets those parameters that it recognizes, while ignoring those it does not recognize.

Due to the arbitrary nature of this parameter set, it is not possible to a priori define specific attributes to carry the individual parameters communicated in this fashion; therefore, a standardized parameter mechanism, such as pre-exists on the object element, should also be supported on audio|video elements.

Furthermore, the data-* attribute mechanism or a non-standardized use of vendor specific x-* attributes are not appropriate, since the former is prohibited from being interpreted by the user agent, and the latter impedes interoperability and goals of standardization.

Finally, the object element itself cannot be used in this case, merely to obtain the use of its param children, without abandoning the new, desirable features supported by the audio|video elements, such as timed text tracks, media controllers, playback and seek semantics, and so forth.

It is therefore requested that the param element be supported as a child of the audio|video elements in a fashion identical to the existing support for param on the object element.

Proposed Changes:

In 4.8.5 (param), change 'Contexts in which this element can be used' to read as follows:

<quote>
As a child of an audio, video, or object element, before any flow content.
</quote>

also in the subsequent prose of 4.8.5, make the following changes:

<quote>
The param element defines parameters for media components or plugins invoked by audio, video, or object elements. It does not represent anything on its own.
</quote>

<quote>
If both attributes are present, and if the parent element of the param is an audio, video, or object element, then the element defines a parameter with the given name-value pair.
</quote>

<quote>
If either the name or value of a parameter defined by a param element that is the child of an audio, video, or object element that represents an instantiated media component or plugin changes, and if that media component or plugin is communicating with the user agent using an API that features the ability to update the media component or plugin when the name or value of a parameter so changes, then the user agent must appropriately exercise that ability to notify the media component or plugin of the change.
</quote>

In 4.8.6 (video), change 'Content Model' to read as follows:

<quote>
If the element has a src attribute: zero or more param elements, then zero or more track elements, then transparent, but with no media element descendants.
If the element does not have a src attribute: zero or more param elements, then zero or more source elements, then zero or more track elements, then transparent, but with no media element descendants.
</quote>

In 4.8.7 (audio), change 'Content Model' to read as follows:

<quote>
If the element has a src attribute: zero or more param elements, then zero or more track elements, then transparent, but with no media element descendants.
If the element does not have a src attribute: zero or more param elements, then zero or more source elements, then zero or more track elements, then transparent, but with no media element descendants.
</quote>
Comment 57 Sam Ruby 2011-09-25 12:53:44 UTC
http://www.w3.org/html/wg/tracker/issues/179