ChangeProposals/issue-179 no change

Issue-179: Counter Change Proposal for No Change

This counter change proposal refers to:

• Issue: http://www.w3.org/html/wg/tracker/issues/179
• Bug: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13333
• Change Proposal: http://www.w3.org/html/wg/wiki/ChangeProposals/av_param

Summary

Issue 179 asks for introduction of a child param element for the audio and video elements to allow the page author to specify arbitrary parameters to the user agent for transporting, decoding, rendering, and controlling the audio or video content.

The av_param change proposal argues that such param elements are known from the object element and are required to allow providing equivalent functionality to the audio and video elements.

This counter change proposal argues that the requirements of the av_param change proposal can already be satisfied with existing HTML features and that no change is necessary. It further argues that the introduction of a param element would require a fundamental change to the way in which audio and video elements are supported in browsers that is not justified by the given use cases.

Rationale

Issue 179 asks for a standardized mechanism by means of which various arbitrary parameters may be communicated to the user agent.

Use Cases

Any introduction of new attributes or elements requires demonstration of good use cases.

The av_param change proposal lists the following use case as an argument to support the need for a param element:

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;

Here is how these are satisfied nowadays:

1. A URL that references the content on a server is provided by the Web developer to HTML audio or video elements through the @src attribute, either directly on the audio or video file, or through the source element. It is also possible to change this dynamically with @src using JavaScript.
2. The value of the "protocolInfo" data structure of the UPnP protocol are described in [1] and exemplified in [2] is given in four parts as *:*:*:* as follows:
   • the protocol for exporting the resource, e.g. http-get, rtsp, rtsp-rtp-udp
   • the network (this is usually "*")
   • the MIME-type of the resource, e.g. audio/m3u, audio/x-ms-wma, image/jpeg, video/mpeg, audio/mpeg, audio
   • additional information (this is usually "*"), e.g. DLNA.ORG_PN=MP3, MICROSOFT.COM_PN=WMALSL, DLNA.ORG_PN=MPEG_PS_NTSC
   with the purpose of checking the compatibility between server and renderer devices for this resource.

The protocol in use in an audio or video element is given through the URL.

The network is the Internet.

If the MIME type needs to be specified explicitly, this can be done through the source element and the @type attribute.

It seems that much of the information that is provided in the additional information field is information that can be extracted directly from the media resource's header fields which is where decoding-specific information resides, and thus does not require additional fields.

However, assuming additional information needs to be specified, this can be provided through one of the existing extensibility mechanisms of HTML:

• data-* attributes allow providing information that is only required for a particular Web page.
• new attributes can be experimented with as x-* attributes and eventually be standardized for use cases that require a standard piece of information to be communicated. The latter seems particularly appropriate given the structure of the additional information field, e.g. x-upnp-dlna="MP3", x-upnp-microsoft="WMALSL", x-upnp-dlna="MPEG_PS_NTSC".
• new document content can be specified by "extensions specifications". This means that in a situation where a different standardisation organisation wants to define an extension such as a param element, they may just go forward with it, may even make it non-conforming, and may specify their own conformance terminology without the W3C HTML specification requiring any change.
• the new data element may possibly also satisfy the need, even though at this stage it is unclear whether it can be used as a child of the video element.

Principle Approach

The Details section in the av_param change proposal suggests that:

The param element defines parameters for media components or plugins invoked by audio, video, or object elements.

Since the audio and video element provide native support for audio and video resource playback in browsers, there is no assumption about how browsers implement media resource parsing, in particular there is no requirement for a plugin framework or a component interface in the HTML specification. Therefore, there is no defined means of propagating parameters from the Web page to the media pipeline. Only parameters and elements that browsers understand can have an effect.

Therefore, the introduction of a generic parameter communication mechanism is not possible without changing the principle by which the audio and video element are defined. It would require introduction of a plugin framework requirement for media elements.

Impact

Positive Effects

To be fully consistent, a param element would need to be introduced as a child not just to audio and video, but also to the source element. This would break existing implementation of the source element, which is currently an empty element. Thus, not introducing it will ensure that existing browser implementations continue to work.

Introducing a param element for communicating any arbitrary information to a media decoding and rendering pipeline can be a breaker of accessibility functionality, since information is passed through the standardized markup layer transparently and deal with away from where browser accessibility APIs have access. Thus, not introducing it will ensure that any such semantic information requires creation of standardised markup and is thus able to be made accessible.

Not following the av_param change proposal will make sure that the HTML specification stays clean of a new extensibility mechanism on the audio and video element that will only be usable by a limited subset of browsers, namely one that uses a plugin architecture for implementing media element support.

Not following the av_param change proposal will ensure that existing extensibility mechanisms will continue to be used for the use cases identified by the av_param change proposal. This in turn will ensure that new use cases for the media elements are properly addressed and result in new standardised attributes and elements in the HTML specification rather than result in special-purpose and incompatible specification branches.

Negative Effects

None.

Conformance Class Changes

No changes.

Risks

None.