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

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

--- Comment #45 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> 2011-07-30 10:19:42 UTC ---
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 10:19:44 UTC