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

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

--- Comment #56 from Glenn Adams <glenn@skynav.com> 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>

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 21 September 2011 02:56:02 UTC