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

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

--- Comment #38 from Glenn Adams <glenn@skynav.com> 2011-07-29 03:18:19 UTC ---
(In reply to comment #37)
> (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?

yes, i could explain, but i perceive it would do no good since you don't seem
to grasp the notion of abstraction layers;

i appreciate your input, but now I'm more interested in hearing from other
parties rather than continuing an apparently fruitless debate with you as a
sole correspondent;

respectfully, 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 03:18:28 UTC