- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 22 Feb 2012 17:07:16 +1100
- To: Glenn Adams <glenn@skynav.com>
- Cc: Mark Watson <watsonm@netflix.com>, Adrian Bateman <adrianba@microsoft.com>, "HTML WG (public-html@w3.org)" <public-html@w3.org>, David Dorwin <ddorwin@google.com>
On Wed, Feb 22, 2012 at 2:32 PM, Glenn Adams <glenn@skynav.com> wrote: > > On Tue, Feb 21, 2012 at 7:04 PM, Mark Watson <watsonm@netflix.com> wrote: >> >> On Feb 21, 2012, at 5:51 PM, Glenn Adams wrote >> >> On Tue, Feb 21, 2012 at 6:35 PM, Adrian Bateman <adrianba@microsoft.com> >> wrote: >>> >>> On Tuesday, February 21, 2012 4:00 PM, Glenn Adams wrote: >>> > This a lengthy proposal that is not directly related to the general >>> > issue of >>> > interchanging decoding and/or protocol parameters between author and >>> > user >>> > agent for the purpose of performing audio and/or video playback. >>> > >>> > Could you point out the specific elements of the proposal that deals >>> > with >>> > such parameter interchange? If this proposal offers an alternative >>> > mechanism >>> > to perform such interchange, then is that mechanism suitable for >>> > purposes not >>> > related to encrypted media playback? >>> >>> Hi Glenn, >>> >>> Rather than introducing a mechanism that supports generic parameter >>> exchange, >>> this proposal shows how it is possible to write an extension >>> specification >>> to add specific functionality to the existing media elements. User Agents >>> supporting this proposal would be interoperable if they implement the >>> extension according to the spec. >>> >>> Having a generic mechanism doesn't guarantee interoperability because you >>> still >>> need to specify what happens for each potential value. I argue that you >>> don't >>> need <param> to do that, you just write the specification that defines >>> the new capabilities you want the media element to support. You can do >>> that with >>> an extension at the time you define the values. >> >> >> Of course that is true, but it is also besides the point. Furthermore, >> your suggestion would lead to the idea that for every extension >> specification ES(0) ... ES(n), one would define an independent mechanism for >> interchanging parameters. >> >> The point of having a generic mechanism is that it is useful in may >> circumstances, in this case a general syntactic mechanism that has been >> successfully implemented and used without requiring changes to the >> originating spec (HTML4 in this case). >> >> I continue to maintain that if there is such a generic parameter >> interchange mechanism defined and included for <object>, then there should >> be such a generic mechanism for <audio> and <video> which seek to define >> specific flavors of <object>. >> >> >> As has been pointed out in the earlier discussion on ISSUE 179, this not >> not correct. <object> embeds *arbitrary* functionality into a page. This >> functionality is constrained only by browser plugin APIs and so can >> literally be almost anything. Hence it makes sense to enable the passing of >> arbitrary parameters. >> >> <video> and <audio>, by contrast, provide the very specific functions of >> media playback. If they were "flavours" of <object> they would provide for >> embedding of arbitrary media playback plugins. They do not. They provide >> access to specific native User Agent media playback functions. > > > I don't agree that <video> or <audio> narrow the functionality of <object> > sufficiently to make <param> unnecessary or undesirable. > > If they did in fact narrow it to this extent then only specific audio, > video, and timed text tracks would have been supported (ogg? webm?), only > specific content protection solutions would have been supported (none?). > >> >> It makes sense in this context to provide specific methods related to this >> functionality. Our proposal introduces specific methods for accessing >> content protection functionality - one of the use-cases that was proposed >> for <param>. > > > Even the proposed content functionality proposal is adopted, it represents > but one use case, and does not invalidate the utility of having a more > generic solution. > > Supporting the use of a generic mechanism recognizes the fact that we do not > at present have perfect or complete knowledge of the set of essential or > useful decoding and/or protocol parameters that will be desired, not only > for today's but also tomorrow's set of fielded audio, video, and timed track > media types and delivery protocols. > > In contrast, failure to define such a mechanism imposes an arbitrary > impedance mismatch between present and past usage (object) and future usage > (audio, video, track), and will likely result in multiple, vendor specific, > adhoc solutions as need is found for interchanging parameters not > represented by presently defined audio, video, and track definitions. > > I would not like to see the use of data-* or x-vendor-* attributes to > support use cases where <param> would suffice. On the contrary: I would not like to see introduction of <param> where data-* or x-vendor-* attributes suffice. These already exist and I have not seen a single use case where <param> was necessary. This proposals shows exactly how extensions are made without a need for <param>. Regards, Silvia.
Received on Wednesday, 22 February 2012 06:08:06 UTC