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

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.

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.

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 08:47:46 UTC