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

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

--- Comment #46 from Glenn Adams <glenn@skynav.com> 2011-07-30 13:31:23 UTC ---
Sylvia,

You persist in wanting to analyze specific parameters and their motivation,
functionality, etc. I have no interest in doing that. I am just offering
additional, published evidence of standardized uses of <param> and don't care
what information they express. This is what I mean by an abstraction layer; on
the other hand, your continued focus on the specific parameters in my numerous
examples reinforces in my mind that you do not consider or understand the value
of the abstraction layer provided by <param>. Or perhaps you have another
agenda here? Perhaps your interest in WebM (which you bring up below) is
driving your comments to find ways to exclude other formats or the existing
architectures that support those other formats? Perhaps you wish to argue that
only those parameters appropriate to WebM should be supported by video/audio,
while ignoring the parametric needs of other formats? Perhaps you wish to argue
that the specific implementation and policy choices adopted by Mozilla should
hold universally? As for me, I support WebM but I also support H.264 and any
other format a content provider wishes to use or a UA or component or framework
or plugin implementer wishes support. I don't know all the parameters needed by
these formats. That is a side effect of the fact the set of format is not
fixed, and therefore, the set of parameters is not fixed. I do know that param
exists and that object works with many formats and uses the param abstraction
to accomplish this in deployed content and browsers. I want video/audio to work
with all formats and implementation architectures. I don't care whether a
browser implements its support for a format internally or via a media framework
or via 3rd party plugins using a plugin architecture. I don't distinguish
between a plugin architecture and a media framework for the purpose of this
discussion. That is an implementation detail outside the scope of HTML5.
Another "abstraction layer" that you don't appear to recognize. I don't like
x-* attributes. They are *always* vendor specific. They are not standard. Their
use has been historically deprecated in by the W3C. They require constant
changes in schemas and DTDs or remain unvalidated. I have shown evidence of
non-vendor specific, standardized param uses, and I believe it would be wrong
to force them to be expressed using x-* attributes. If I have to choose among
existing alternatives without having param, then I would choose data-*
attributes and ignore the prohibition in HTML5 against such use in a UA
specific fashion.

Yes, I am talking to a variety of people about this issue, and yes, there is
support not only for the problem statement but the proposed solution. I intend
to escalate this as needed to obtain resolution by determining a consensus in
this larger community.

G.

(In reply to comment #45)
> Dear Glenn,
> 
> "A plugin is, quite simply, a third party library that “plugs in” to the
> browser that can be embedded inside a web page using an <embed> tag or a
> <object> tag.  Many of them then draw pretty pictures or animations, though
> that’s not required.  Many allow you to talk to them through javascript,
> though that’s not required.  In short, a plugin affects only a specific page
> in which it is placed."
> http://colonelpanic.net/2010/08/browser-plugins-vs-extensions-the-difference/
> 
> "Plugins have to either handle a mime type or be embedded into a web page. 
> They don’t get put there automatically. They don’t create toolbars.  They
> don’t affect browser menus.  They don’t know about tabs, or even about
> other pages in the same browser process.  They don’t make coffee, tea, or hot
> chocolate, though they could be written to control an external appliance to do
> so if you really wanted.  They don’t automatically process the content of
> every web page loaded."
> 
> OK, now that we know who has a problem with abstraction layers, maybe we can
> move back to a technical conversation about the HTML5 specification. Since I am
> aware that there may be a large number of people that you are communicating
> with about this, I will continue to try and help and ignore the attitude.
> 
> I assume the type of plugins that you may be thinking about for extending the
> functionality of the <video> element may not be the usual browser plugins. They
> may be more akin to the way in which you can gain WebM support in IE: namely
> through a Media Foundation component (http://tools.google.com/dlpage/webmmf).
> Indeed, IE, Chrome, and Opera use media frameworks to provide media resource
> decoding for <video> and <audio>. But even then: most of them have disabled the
> ability to generally support all codecs installed on a system and restrict this
> to a given list. More fundamentally though: Firefox does not use such a
> framework and instead only provides support for specific compiled-in codecs.
> 
> Thus, proposing a generalised framework for communicating video decoding and
> display parameters to a specialised decoder in a custom browser just isn't
> relevant to the majority of browsers.
> 
> Now, I think there is a more fundamental problem with your approach than the
> sheer mechanics of implementation: You are trying to meld the new HTML5
> standard onto existing standards that have prescribed <object> for video
> published. That's fundamentally the wrong approach towards <video> and <audio>.
> Instead, you should adapt those standards to the new HTML5 specification. This
> requires understanding what the <audio> and <video> elements already provide
> and mapping the use cases that have been specified to be implemented through
> specific <param> values to the existing attributes of <audio> and <video>. Any
> remaining use cases should either also be standardised in HTML5, or use the x-*
> attribute extension mechanism.
> 
> To examplify what I mean, I'll give you some hints in the list that you
> provided below.
> 
> 
> (In reply to comment #44)
> > (In reply to comment #43)
> ...
> > 1) The “type” attribute SHALL be included to define the MIME-type used for
> > the audio or
> > video profile that matches the content referred to by the value of the
> > “data” attribute.
> 
> 
> The mime type of the video or audio element's resource can be provided through
> the @type attribute of a <source> element like this:
> 
> <video>
>   <source src="yourfile.ext" type="mime/type">
> </video>
> 
> 
> > 2) An <object>-element SHOULD contain a <param>-element dlna_res_attr which
> > SHALL
> > contain the media properties attributes associated with the content resource
> > that is
> > referred to by the value of the data attribute.
> ...
> 
> Not quite sure what this is and why any more than the URL would be required to
> specify the media properties, but this seems a clear example for something that
> is specific to a particular application domain and not the general Web. So, a
> custom attribute is probably useful. Something like this:
> 
> <video>
>   <source src="yourfile.ext" type="mime/type"
> x-dlna-res-attr="protocolInfo=rtsp-rtp-udp:*:audio/mpeg:*">
> </video>
> 
> 
> > 3) An <object>-element of type video (as defined by [Req 5.7.1.b]) SHOULD
> > contain a
> > <param>-element to set the aspect ratio parameter of this object. This is an
> > initial aspect
> > ratio of the video content."
> ...
> 
> 
> The aspect ratio of HTML5 video will always be retained and end up in
> pillarboxed or letterboxed video if the video viewport doesn't match. For
> changing this, we have CSS, in particular the object-fit and object-position
> styles that help adapt positioning and aspect ration changes within the video
> viewport. This is a more practical way of dealing with aspect ratio than trying
> to tell a decoder what aspect ratio a video should be decoded to.
> 
> 
> > b. <param name=”loop” value=”…”/> - sets the number of times the A/V
> > content SHALL
> > be played. A/V playback SHALL be automatically restarted if the end of content
> > is reached
> > and the content has not been played the number of times indicated by the loop
> > parameter.
> > The value of this parameter SHALL be either:
> > 
> >   i. the number of times (> 0) that the content SHALL be played, OR
> > 
> >   ii. “infinite” if the content SHALL be looped continuously.
> >   If the AV Player is reinitialized (i.e. the data or type attribute has
> > changed as per [Req.
> >   5.7.1.l]), the indicated loop count SHALL be automatically re-applied by the
> > Remote UI
> >   Client. If the AV player is stopped or paused, and subsequently restarted,
> > the current
> >   pending loop count SHALL remain in effect. If missing, the default value of
> > the loop
> >   parameter SHALL be 1.
> 
> 
> <video> and <audio> have a @loop attribute. You could, however, make a case for
> it to have the values that your param is proposing rather than being a boolean
> attribute if you saw a need for it. 
> 
> 
> > c. <param name=”autostart” value”…”/> - used for indicating whether
> > or not the A/V
> > Player scripting object SHALL behave as if an initial play(1) method call was
> > automatically issued.
> 
> <video> and <audio> have the @autoplay attribute for this.
> 
> ...
> > d. <param name=”avControlMode” value=”…”/> - This parameter is used
> > to set the
> > playback control mode of the A/V control scripting object.
> 
> <video> and <audio> have the @controls attribute for this.
> 
> ...
> 
> 
> > As can be seen, the set of "standardized" param names/values increases/changes
> > over time in such a manner as to preclude an a priori definition of new
> > attributes.
> 
> No, you haven't proven this at all. Most of the parameters that you are asking
> for already exist. And for others we have the x-* extensions. I have only seen
> one such extension need above which does not constitute an "explosion of
> attributes".
> 
> I would suggest that a detailed analysis of the needs that your suggested
> <param> element would satisfy is the right way to progress. You may find - as
> above - that most needs are already satisfied by existing attributes.

-- 
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 Saturday, 30 July 2011 13:31:26 UTC