Re: an interoperable object (fallback and context menus)

At this point this discussion really belongs in the
plugin-futures@mozilla.org mailing list. There's not much we can do
here other than agree that a richer NPAPI would be great.

What would be appropriate for the HTML list is to specify how plugins
should behave.

/ Jonas

On Fri, Mar 13, 2009 at 7:25 PM, Robert J Burns <rob@robburns.com> wrote:
> Hi Maciej DavidB, and Boris,
> On Mar 13, 2009, at 4:15 PM, Maciej Stachowiak wrote:
>
> On Mar 13, 2009, at 12:39 PM, Boris Zbarsky wrote:
>
> Maciej Stachowiak wrote:
>
> In general, Safari, Opera and Gecko try to coordinate NPAPI changes via
> plugin-futures and even though not every browser implements all recent
> additions, we do at least try to design them not to be specific to one
> browser.
>
> Right; I'm not suggesting that the intrinsic size API wouldn't be designed
> in such a way that all the browsers involved can implement it.  Just that I
> can't speak on behalf of anyone but Gecko in terms of wanting to implement
> it.  ;)
>
> I think a way for plugins to report intrinsic size would be a useful general
> addition to the plugin API.
>
> From the discussion surrounding the 'object' element I think this suggestion
> may be merely the tip of the iceberg.
> Other parameters (many read/write) that would be useful to share between UA
> and plugins:
>  - contextual menu enhancement (where the UA creates the contextual menu but
> provides space for the plugin to add items as Leif's test demonstrate[1])
>  - parameters for
>     -- spatial (note these would only be one part of the information used to
> determine the displayed dimensions)
>        * inherent dimensions
>        * inherent aspect ratio
>    --  temporal
>        * play/pause
>        * frame
>        * time-index
>    --  audible
>        * volume level
>        *  mute
>        * balance
>        * alternate audio tracks (listing, enabling/disabling, volume levels)
>    --  text equivalents (subtitles and captions)
>        * listing of available text equivalents: captions and subtitles
>        * enabling / disabling of one or more text equivalent
>        * spatial arrangement of one or more text equivalent
> Obviously not all of these suggested parameter interfaces apply to all
> plugins. However, by allowing plugins to opt into these we can provide a
> richer experience for users and build accessibility into documents by
> default. Similarly, whenever an object for a particular plugin has
> focus, controls corresponding to these parameters can be made available to
> the user (including disabled users). For example, a video plugin may make
> use of all of these interfaces while an audio plugin may only use the
> temporal and audible interfaces. A specialized application/* plugin might
> make use of a completely different set. An audio content handler plugin
> might even make use of spatial parameters to, for example, display
> an oscilloscope
> What this means is that the simple authoring approach ("<object
> data='resource'>fallback/alternate text</object>") is all that an author
> requires for most use cases to gain a rich user experience and complete
> accessibility. Obviously an author may want to do more, but this makes the
> simple things simple and the complicated things possible. This is the type
> of approach that makes documents accessible by default with the most limited
> authoring burden.
> This also allows a UA (cooperating with a plugin) to provide complete user
> interface controls for these features (automatically accessible from the
> HTML authors perspective).
> This doesn't have to be NPAPI-specific. HTML5 (or another spec) could define
> a set of plugin requirements for a UA plugin architecture and any plugin API
> could then conform to those requirements. It is remarkable given the broad
> scope of the HTML5 draft that plugin architecture has not taken a more
> significant role.
> Take care,
> Rob
> [1]: <http://www.malform.no/html5/object>

Received on Saturday, 14 March 2009 02:43:06 UTC