W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: ISSUE-9: video-synchronization - suggest closing on 2009-08-27

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 24 Aug 2009 23:58:30 -0700
To: Joe D Williams <joedwil@earthlink.net>
Message-id: <BC02CEB1-E2B5-4300-9146-D5FCE2C9249B@apple.com>
Cc: Dan Connolly <connolly@w3.org>, public-html@w3.org
Hi Joe,

On Aug 24, 2009, at 8:37 PM, Joe D Williams wrote:

>> something about mechanisms provided by <object param=...> that
>> don't seem to be provided by <video>. I hope somebody sends
>> mail about that soon
>
> Hi,
> I think it isn't about
>
> <object param='xx'
>
> it is about
> <object type='mime' ... other standard attrs>
> <param name='xxx' value='ccc'>
> <param name='ddd' value='eee'>
> ...maybe more optional <param> elements
> <fallbackhtml> stuff></fallbackhtml>
> </object>
>
> The param elements establish DOM interfaces to and from the nested  
> context.
> In general, the best use of <param> elements I have seen is to  
> provide optional or required runtime info to and from the native  
> device or plugin device that is running the content. The <param>(s)  
> give ways to transport name-value pairs that are not defined as part  
> of the standard html language <object> interface. It is complicated,  
> but the general idea is that the host may get the embedded or native  
> application running then send and receive runtime stuff through the  
> params. If the info is defined, like for media elements such as  
> <video> that have a list of standard attributes, the configurable  
> params are not now provided.
>

Yes, this is what is generally used to pass initialization parameters  
to plugins invoked via <object>. Since the capabilities of plugins are  
completely open-ended, it's hard to define attributes up front that  
pass in the needed information.

What I'm not clear on is how this would apply to <video> or <audio>.  
These have a limited purpose, and parameters can be passed in via the  
predefined attributes on the element. In existing implementations, the  
set of codecs is either hardcoded or serviced by a more limited plugin  
interface that cannot accept arbitrary parameters. I'm not totally  
sure I follow all of your message, but it seems like maybe you are  
saying the same thing, that <param> doesn't seem like it makes sense  
for a fixed-function element like <video>.

So I'm not really clear on what <param> elements for <video> or  
<audio> would do. Can anyone give a concrete example of how <param>  
might be used with these elements?

Regards,
Maciej
Received on Tuesday, 25 August 2009 06:59:12 UTC

This archive was generated by hypermail 2.3.1 : Friday, 10 October 2014 16:24:51 UTC