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

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

--- Comment #34 from Glenn Adams <glenn@skynav.com> 2011-07-28 14:01:45 UTC ---
(In reply to comment #31)
> (In reply to comment #27)
> > (In reply to comment #25)
> > 
> > you have failed to offer a viable alternative to this proposal, all you have
> > offered either doesn't work or violates some prohibition or convention; just to
> > review, you have said:
> > 
> > * use data-*
> > * use non-standard attributes in HTML syntax
> > * use object
> > * use JS parameters to non-standard JS interfaces
> 
> 
> No, I have pointed to http://dev.w3.org/html5/spec/Overview.html#extensibility 
> which tells you how to extend in a standard way. You're trying to introduce
> another means of extensibility which is simply not necessary.
> http://dev.w3.org/html5/spec/Overview.html#extensibility in particular mentions
> that you can do proprietary attributes by using "x-*" named attributes. So, why
> don't you just use "x-param" if that's what you need?

Because (1) we would need:

x-param-1
x-param-2
x-param-3
...
x-param-n

where n increases over time.

Because (2) this would introduce a disparity between HTML and XHTML syntaxes,
and would require:

foo:x-param-1
foo:x-param-2
foo:x-param-3
...
foo:x-param-n

for XHTML, and who would own "foo"?

Because (3) this method may require modifying a UA for every new x-param-*
added, instead of having a generic mechanism like <param> which can be
collected by the UA parser (for video/audio) and passed a collection to the
video/audio component/plugin as a single entity irrespective of which
parameters are present.

Because (4) use of x-* attributes REDUCES interoperability and partitions
content and implementations.

> Incidentally, anything that is just implemented and implementable by a subpart
> of browsers is proprietary. The kind of DRM schemes that you are thinking about
> probably rely on having closed source code and therefore cannot be implemented
> for example in Firefox. Thus, it's proprietary.

In that case, every browser is "proprietary" by your definition, since every
browser implements a different subpart of HTML5 and related specs.

Firefox supports a plugin architecture that will undoubtedly be used for
video/audio. As such, it does not necessarily include or ship with DRM enabled
plugins from Mozilla. But that does not prevent such plugins from supporting
DRM today using object.

Why should the change from object from video/audio cause the param mechanism to
be removed?

Why should authors have to choose between using (1) object plus param to obtain
compatibility with current practice (including) DRM and (2) video/audio minus
param to obtain the new functionality of the latter while losing the
functionality of the former.

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 Thursday, 28 July 2011 14:01:55 UTC