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

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

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

-- 
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 Friday, 29 July 2011 17:58:35 UTC