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

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

--- Comment #37 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-07-29 02:46:17 UTC ---
(In reply to comment #34)
> (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.


I think that's a completely adequate approach and most appropriate for
standardisation. First you determine there is a need for a specific attribute
(parameter), so you start using it and it gets implemented in a browser. Then
that parameter becomes more relevant to other browsers, too. So, eventually it
is adopted as a standard for the media elements and loses the "x-". That's
perfectly do-able and scales with 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"?


You said that the idea is to have the params in use be standardised by other
entities/organisations so they can provide parameters that are useful to their
needs. It would, obviously, be that organisation then that chooses the
namespace.


> 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.

Every new param has to result in new code in either a browser or a plugin. So,
I don't see a problem with having a new x-param-* introduced for it either.
Also, if you really don't want that, you can always choose the second way that
I proposed: x-param="yourfavoriteparameter=paramvalue" or something similar.
The value of the parameter is totally up to the application to choose.


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


So do the <param> elements. How do you suggest making sure that the parameters
stay interoperable between different browsers and plugins?



> > 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.


There's a difference between features that have not been implemented yet by all
browsers, but are part of a specification, and features that are never meant to
be implemented by all browsers.


> 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.


Yup. Plugins are your solution, as I keep saying.


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

Because param is for a communication between the Web page and plugins. The
video and audio element are not designed to be used by plugins. They are
instead designed to be used by specific resource types.


> 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.

So, you are suggesting that the <video> and <audio> elements not be interpreted
by the browser, but by a plugin? I fail to see how you want to communicate from
a <param> element in the <video> or <audio> element to a plugin that has not
been placed into the Web page through <object> or <embed>. Can you explain?

-- 
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 02:46:19 UTC