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

Hi Maciej,

> What I'm not clear on is how this [<param>] would apply to <video> 
> or <audio>.

I'm not sure either. When I read the comment about <param> I had a 
passing idea that a set could be used to pass info that was not 
'standard' in html but might be somehow usable to assistive tech. But 
I don't have any actual idea of what the info might be. If I was 
aiming at a specific tool, then the tool might have some special 
keywords and data it recognized to produce some interaction, but I 
don't know of anything specific.

Thanks and Best Regarrds,
Joe


----- Original Message ----- 
From: "Maciej Stachowiak" <mjs@apple.com>
To: "Joe D Williams" <joedwil@earthlink.net>
Cc: "Dan Connolly" <connolly@w3.org>; <public-html@w3.org>
Sent: Monday, August 24, 2009 11:58 PM
Subject: Re: ISSUE-9: video-synchronization - suggest closing on 
2009-08-27


> 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 14:16:52 UTC