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

On Aug 28, 2009, at 1:30 AM, Joe D Williams wrote:

> Hi again Maciej,
>
>>> ...<param> ... Yes, this is what is generally used to pass  
>>> initialization parameters
> to plugins invoked via <object>
>
> Not only for initialization, but these names can represent live  
> interfaces accessible using the host DOM. For example, as well as  
> initialization a common use of <param> is defining an interface tor  
> sending a target content uri into the plugin. Somehow the host  
> context and nested context agree on a list of these nonstandard  
> (that is, not listed in the html standard) interfaces. The <param>s  
> included by the author are sent during initialization then can be  
> live while the plugin is running. Any <param>s not recognized by the  
> nested context are ignored.
>
> That is where the association with assistive tech comes in. A set of  
> <param> elements (and DOM listeners) could define hooks between  
> assistive technology and the plugin so that, for example, the at  
> could take control of the object.

You can't use <param> elements to talk to an <object> element on the  
fly. In practice when you do this, browsers re-initialize the plugin.  
For the use case of communicating with a running plugin without  
restarting it, browsers allow plugins to expose a scripting interface  
to JavaScript.

>
> Now, since all appropriate standardized interfaces for <audio> and  
> <video> are defined, those objects don't need <param> anymore. Oops  
> that statement leads me to think of course <param name='' value=''>  
> should be allowed as a general-purpose opportunity for the host and  
> plugin to communicate in all mixed embedded content elements  The  
> host browser could be free to ignore <param name='' value=''>  
> everywhere else but <object>.
>
> Again, nothing concrete concerning actual application connections.  
> At most <param> could be a general hook for audio/video/iframe/ 
> canvas/object and any live content where extensions of the standard  
> html interfaces might help.

audio, video, iframe and canvas do not emebd plugins, they are built- 
in content. So I don't see how this applies.

  - Maciej

>
> Thanks and Best Regards,
> Joe
>
>
>
> .
> ----- Original Message ----- From: "Joe D Williams" <joedwil@earthlink.net 
> >
> To: "Maciej Stachowiak" <mjs@apple.com>
> Cc: "Dan Connolly" <connolly@w3.org>; <public-html@w3.org>
> Sent: Tuesday, August 25, 2009 7:16 AM
> Subject: 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 Friday, 28 August 2009 09:03:22 UTC