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

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

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

-- 
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, 27 July 2011 04:12:05 UTC