- From: Joe D Williams <joedwil@earthlink.net>
- Date: Tue, 25 Aug 2009 07:16:08 -0700
- To: "Maciej Stachowiak" <mjs@apple.com>
- Cc: "Dan Connolly" <connolly@w3.org>, <public-html@w3.org>
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