Re: an interoperable object (fallback and context menus)

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>