ChangeProposals/av param

From HTML WG Wiki
< ChangeProposals
Revision as of 00:35, 29 October 2011 by Gadams (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Change Proposal

Summary

The audio and video elements fail to provide a standards compliant mechanism to specify arbitrary parameters that may be used by the user agent to fetch, decode, and present the referenced media resource. In contrast, the object element does provide such a mechanism, the param element. This issue requests that the param element be permitted as a child for both audio and video elements in order to provide equivalent functionality to that afforded to implementations in prior versions of HTML.

Rationale

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 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. Regarding the data-* attribute mechanism, HTML5 specifically prohibits interpretation by the user agent [1]:

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.

and also

These attributes are not intended for use by software that is independent of the site that uses the attributes.

In the usage scenarios addressed by this issue, the media component, i.e., the implementation of the audio or video media codec and renderer in the User Agent, would directly support the interpretation of specific param name and value pairs, and would do so in a manner independently from the site specifying the parameters. It is expected that support for specific parameters by a class of user agents would be specified or documented in other specifications outside the context of the HTML5 specification.

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.

Details

In 4.8.5 (param)

Change Contexts in which this element can be used to read as follows:

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

also in the subsequent prose, make the following changes:

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.

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.

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.

In 4.8.6 (video)

Change Content Model to read as follows:

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.

In 4.8.7 (audio)

Change Content Model to read as follows:

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.

Impact

Positive Effects

  1. provides continuity for the use of video/audio content when migrating from the object element as defined in HTML4
  2. permits use of new features of video/audio, such as accessibility features, that would not be afforded if content author is required to use the object element in HTML5 in order to express parameters;
  3. provides standards compliant mechanism for expressing arbitrary parameters for video and audio elements that are not yet supported by existing attributes on video and audio elements;

Negative Effects

None identified

Conformance Classes Changes

None identified

Risks

None identified

References