- From: Joe D Williams <joedwil@earthlink.net>
- Date: Fri, 28 Aug 2009 01:30:05 -0700
- To: "Joe D Williams" <joedwil@earthlink.net>, "Maciej Stachowiak" <mjs@apple.com>
- Cc: "Dan Connolly" <connolly@w3.org>, <public-html@w3.org>
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