Les Bases des Greffons

Cette page est en cours de traduction, son contenu peut donc être incomplet ou contenir des parties en anglais. N'hésitez pas à participer à sa traduction à partir de en/Gecko_Plugin_API_Reference/Plug-in_Basics

Comment les greffons sont utilisés

Les greffons proposent de multiples capacités pour augmenter la flexibilité des navigateurs basés sur Gecko. Voici quelques exemples :

  • Afficheurs multimedia tels qu'Adobe Flash et Adobe Acrobat
  • Utilitaires pour embarquer des objets ou fournissant des services de compression/décompression.
  • Des applications allant des gestionnaires d'informations personnelles aux jeux.

Le champs de possibilités permis par l'utilisation de la technologie des greffons semble immense comme le démontre le nombre croissant de fournisseurs de logiciels indépendants en produisant.

Avec l'API Greffons vous pouvez créer des greffons chargés dynamiquement pouvant :

  • Enregistrer un ou plusieurs types MIME
  • Dessiner dans une zone d'une fenêtre de navigateur.
  • Récupérer des évènements clavier/souris.
  • Récupérer des données du réseau via des URLs.
  • Poster des donner à des URLs.
  • Ajouter des hyperliens ou des zones interactives (hotspot) reliant à de nouvelles URLs.
  • Dessiner dans des sections de pages HTML.
  • Communiquer avec JavaScript/DOM depuis du code natif.

Vous pouvez voir quels greffons sont installés sur votre système et correctement associés avec le navigateur en consultant la page des Plugins (greffons) Installés. Allez dans le menu Aide, cliquez sur Aide puis A propos des plugins. Vous pouvez aussi, taper "about:plugins" dans la barre d'adresse. La page des Plugins Installés liste chaque greffon avec ses types ou types MIME, sa description, extensions de fichiers et l'état courant du greffon (activé ou non) pour chaque type MIME qui lui est assigné. Remarquez dans "Code source de la page" comme ces informations sont simplement collectées depuis JavaScript.

Du fait que les greffons soient spécifiques à une plateforme donnée, vous devez les porter pour chaque système d'exploitation et type de processeur sur lesquels vous voulez les déployer.

Greffons et applications aidantes

Avant les greffons existaient les applications aidantes. Une application aidante est une application séparée et indépendante qui peut être lancée depuis le navigateur. Comme pour un greffon, il la démarre quand il doit traiter un type MIME qui y mène. Contrairement aux greffon, une application aidante fonctionne séparément du navigateur dans son propre espace et n'interagit pas avec le navigateur ou le web.

Quand le navigateur doit traiter un type MIME, il cherche toujours en premier un greffon enregistré pour. S'il n'y à pas de résultat, il cherche une application aidante.

Les greffons et les applications aidantes remplissent différents besoins. Pour plus d'information à propos de ces dernières, référez-vous à l'aide en ligne de Netscape.

Comment les greffons fonctionnent

Le cycle de vie d'un greffon, à la différence de celui d'une application, est entièrement contrôlé par la page web qui l'appelle. Cette section vous donne un aperçu de la manière dont les greffons agissent au sein du navigateur.

Lorsque Gecko démarre, il cherche des greffons à certains emplacements spécifiques du système. Pour plus d'information sur les endroits en question selon les systèmes d'exploitation, regardez Comment Gecko trouve les greffons.

Quand l'utilisateur ouvre une page contenant des données embarquées d'un type de média invoquant un greffon, le navigateur répond par la séquence d'actions suivante :

  • Recherche d'un greffon correspondant au type MIME
  • Chargement du code du greffon en mémoire
  • Initialisation du greffon
  • Création d'une nouvelle instance du greffon

Gecko peut chargé plusieurs instances d'un même greffon dans une seule page ou dans plusieurs pages ouvertes au même moment. Si vous naviguez sur une page ayant plusieurs clips RealAudio, par exemple, le navigateur crée autant d'instances du greffon RealAudio que nécessaire (Quoique lire plusieurs fichiers RealAudio simultanément soit rarement une bonne idée évidemment). Quand l'utilisateur quitte la page ou ferme la fenêtre, l'instance est supprimée. À la suppression de la dernière instance, le code du greffon est déchargé de la mémoire. Il ne consomme alors aucune ressource si ce n'est de l'espace disque. La section suivante, Comprendre le Modèle d'Exécution, décrit ces étapes en détail.

Comprendre le Modèle d'Exécution

Les greffons sont des modules de code dynamique associés à un ou plusieurs types MIME. Au démarrage du navigateur, il énumère ceux qui sont disponibles (cette étape diffère d'une plateforme à l'autre), lit les ressources depuis chaque fichier du greffon traité pour déterminer les types MIME qu'il gère et, selon ces derniers, enregistre chaque librairie du greffon.

L'étape suivant esquisse d'un greffon depuis son chargement jusqu'à sa suppression :

  • Quand Gecko trouve des données d'un type MIME associé à un greffon (aussi bien embarqué dans du HTML que dans un fichier séparé), il en charge le code dynamiquement (si ce n'est pas déjà fait) et en crée une nouvelle instance.

Gecko appelle la fonction NP_Initialize de l'API Greffons au premier chargement du greffon. Par convention, toutes les fonctions spécifiques aux greffons ont le préfixe "NPP" et celles spécifiques au navigateur ont "NPN".

NOTE: NP_Initialize et NP_Shutdown ne font techniquement pas partie de la liste des fonctions que le greffon remet au navigateur. Ce dernier les appelle quand il le charge et  le décharge. Ces fonctions sont exportées depuis la librairie dynamique du greffon et (a traduire : accessed with a system table lookup). Elles ne sont donc reliées à aucune instance de greffon. Encore une fois, jetez un œil à Initialisation et Destruction pour de plus amples détails

  • Le navigateur appelle la fonction NPP_New de l'API Greffons à la création de l'instance. Plusieurs instances du même greffon peuvent exister (a) s'il y à plusieurs objets embarqués sur une page ou (b) si plusieurs fenêtres sont ouvertes affichant chacune le même type de données.
  • Une instance de greffon est supprimée lorsqu'un utilisateur quitte sa page ou ferme sa fenêtre. Gecko appelle NPP_Destroy pour informer le greffon de la destruction de l'instance.
  • A la destruction de la dernière instance du greffon, le code du greffon est déchargé. Gecko appelle la fonction NP_Shutdown. Déchargé, le greffon ne consomme aucune autre ressource que de l'espace disque.

NOTE: Les appels et rappels de l'API Greffons utilisent le thread principal du navigateur. De manière générale, si vous voulez contrôler vos opérations par l'ajout de nouveaux threads tout au long de l'exécution du greffon, vous devrez faire attention à les isoler des appels de L'API Greffons.

Lisez Initialisation et Destruction pour plus d'information concernant ces méthodes.

Détection de Greffons

Gecko cherche les greffons à plusieurs endroits et ce dans un ordre bien précis. La section qui suit Comment Gecko trouve les greffons décrit ces règles et la suivante Checking Plug-ins by MIME Type décrit comment vous pouvez vous servir de JavaScript pour localiser les greffons vous-mêmes et les affecter aux différents types MIME.

Comment Gecko trouve les greffons

Lorsqu'un navigateur fondé sur Gecko démarre sur Windows ou Unix, il vérifie la présence de modules de greffons à l'endroit ciblé par MOZ_PLUGIN_PATH. Après quoi il recherche la plateforme voulue dans le dossier du greffon :

  • MS Windows : plugins subdirectory, in the same directory as the browser application.
  • Mac OS X: Plugins are loaded from within the application bundle in the following locations: BUNDLE/Contents/Plug-Ins and BUNDLE/Contents/MacOS/plugins. Also, the browser scans ~/Library/Internet Plugins then /Library/Internet Plugins. Within these directories, the plug-ins are ordered by date.
  • Unix: usr/local/lib/netscape/plugins or $HOME/.mozilla/plugins. If you want to use a different directory, set the MOZ_PLUGIN_PATH environment variable to its filepath, for example, $HOME/yourplugins:/usr/local/lib/netscape/plugins. Gecko searches any directory that this variable specifies. The localuser location, if it exists, overrides the network location.

On all platforms, the plug-ins subdirectory or folder must be in the same directory as the browser application. Users can install plug-ins in this directory manually, by using a binary installer program, or by using the XPInstall API to write an installation script, which the browser then uses to perform the installation. For more information about these options, see Installing Plug-ins.

To find out which plug-ins are currently installed visit about:plugins. Gecko displays a page listing all installed plug-ins and the MIME types they handle, as well as optional descriptive information supplied by the plug-in.

On Windows, installed plug-ins are automatically configured to handle the MIME types that they support. If multiple plug-ins handle the same MIME type, the first plug-in registered handles the MIME type. For information about the way MIME types are assigned, see Registering Plug-ins.

Checking Plug-ins by MIME Type

The enabledPlugin property in JavaScript can be used to determine which plug-in is configured for a specific MIME type. Though plug-ins may support multiple MIME types and each MIME type may be supported by multiple plug-ins, only one plug-in can be configured for a MIME type. The enabledPlugin property is a reference to a Plugin object that represents the plug-in that is configured for the specified MIME type.

You might need to know which plug-in is configured for a MIME type, for example, to dynamically create an object element on the page if the user has a plug-in configured for the MIME type.

The following example uses the JavaScript to determine whether the Adobe Flash plug-in is installed. If it is, a movie is displayed.

// Can we display Adobe Flash movies?
var mimetype = navigator.mimeTypes["application/x-shockwave-flash"];

if (mimetype) {
   // Yes, so can we display with a plug-in?
   var plugin = mimetype.enabledPlugin;
   if (plugin) {
      // Yes, so show the data in-line
      document.writeln("Here\'s a movie: <object data='mymovie.swf' height='100' width='100'></object>");
   } else {
      // No, so provide a link to the data
      document.writeln("<a href='mymovie.swf'>Click here</a> to see a movie.");
   }
} else {
   // No, so tell them so
   document.writeln("Sorry, can't show you this movie.");
}

Overview of Plug-in Structure

This section is an overview of basic information you will need as you develop plug-ins.

 

Understanding the Plug-in API

A plug-in is a native code library whose source conforms to standard C syntax. The Plug-in Application Programming Interface (API) is made up of two groups of functions and a set of shared data structures.

  • Plug-in methods are functions that you implement in the plug-in; Gecko calls these functions. The names of all the plug-in functions in the API begin with NPP_, for example, NPP_New. There are also a couple of functions (i.e., NP_Initialize and NP_Shutdown), that are direct library entry points and not related to any particular plug-in instance.
  • Browser methods are functions implemented by Gecko; the plug-in calls these functions. The names of all the browser functions in the API begin with NPN_, for example, NPN_Write.
  • Data structures are plug-in-specific types defined for use in the Plug-in API. The names of structures begin with NP, for example, NPWindow.

All plug-in names in the API start with NP. In general, the operation of all API functions is the same on all platforms. Where this varies, the reference entry for the function in the reference section describes the difference.

 

Plug-ins and Platform Independence

A plug-in is a dynamic code module that is native to the specific platform on which the browser is running. It is a code library, rather than an application or an applet, and runs only from the browser. Although plug-ins are platform-specific, the Plug-in API is designed to provide the maximum degree of flexibility and to be functionally consistent across all platforms. This guide notes platform-specific differences in coding for the MS Windows, Mac OS X, and Unix platforms.

You can use the Plug-in API to write plug-ins that are media type driven and provide high performance by taking advantage of native code. Plug-ins give you an opportunity to seamlessly integrate platform-dependent code and enhance the Gecko core functionality by providing support for new data types.

The plug-in file type depends on the platform:

  • MS Windows: .DLL (Dynamic Link Library) files
  • Unix: .SO or .DSO (Shared Objects) files
  • Mac OS X: PPC/x86/Universal loadable Mach-O bundle

Windowed and Windowless Plug-ins

You can write plug-ins that are drawn in their own native windows or frames on a web page. Alternatively, you can write plug-ins that do not require a window to draw into. Using windowless plug-ins extends the possibilities for web page design and functionality. Note, however, that plug-ins are windowed by default, as windowed plug-ins are in general easier to develop and more stable to use.

  • A windowed plug-in is drawn into its own native window on a web page. Windowed plug-ins are opaque and always come to the top HTML section of a web page.
  • A windowless plug-in need not be drawn in a native window; it is drawn in its own drawing target. Windowless plug-ins can be opaque or transparent, and can be invoked in HTML sections.

Whether a plug-in is windowed or windowless depends on how you define it.

The way plug-ins are displayed on the web page is determined by the HTML element that invokes them. This is up to the content developer or web page author. Depending on the element and its attributes, a plug-in can be visible or hidden, or can appear as part of a page or as a full page in its own window. A web page can display a windowed or windowless plug-in in any HTML display mode; however, the plug-in must be visible for its window type to be meaningful. For information about the way HTML determines plug-in display mode, see "Using HTML to Display Plug-ins."

 

The Default Plug-in

When a specific plug-in is not registered to handle the media referred to in the HTML, Gecko invokes the default plug-in to help users find and install the right plug-in for that MIME type.

The blue puzzle piece that appears in the HTML page's plug-in window when the default plug-in loads is meant to signify that the browser is missing a piece that it needs to display or play the requested media.

image:plugin_puzzle.gif

How the plug-in HTML element was coded determines what action is taken when the user clicks the plug-in piece. If the browser cannot handle the given MIME type, then the default plug-in checks to see if there is a plug-in referenced in the object element that defines the media. If there is, then thedefault plug-in prompts the user to download that plug-in from the specified location. If a plug-in is not specified in the object element, then the default plug-in looks for child elements, such as other object element, which will provide more specific information about how to handle the specified media type.

Using HTML to Display Plug-ins

When a user browses to a web page that invokes a plug-in, how the plug-in appears (or does not appear) depends on two factors:

  • The way the developer writes the plug-in determines whether it is displayed in its own window or is windowless.
  • The way the content provider uses HTML elements to invoke the plug-in determines its display mode: whether it is embedded in a page, is part of a section, appears on its own separate page, or is hidden.

This section discusses using HTML elements and display modes. For information about windowed and windowless operation, see Windowed and Windowless Plug-ins.

For a description of each plug-in display mode, and which HTML element to use to achieve it, go on to Plug-in Display Modes. For details about the HTML elements and their attributes, go on to:

Plug-in Display Modes

Whether you are writing an HTML page to display a plug-in or developing a plug-in for an HTML author to include in a page, you need to understand how the display mode affects the way plug-ins appear.

A plug-in, whether it is windowed or windowless, can have one of these display modes:

  • embedded in a web page and visible
  • embedded in a web page and hidden
  • displayed as a full page in its own window

An embedded plug-in is part of a larger HTML document and is loaded at the time the document is displayed. The plug-in is visible as a rectangular subpart of the page (unless it is hidden). Embedded plug-ins are commonly used for multimedia images relating to text in the page, such as the Adobe Flash plug-in. When Gecko encounters the object or embed element in a document, it attempts to find and display the file represented by the data and src attributes, respectively. The height and width attributes of the object element determine the size of the embedded plug-in in the HTML page. For example, this object element calls a plug-in that displays video:

<object data="newave.avi" type="video/avi" 
        width="320" height="200"
        autostart="true" loop="true">
</object>

A hidden plug-in is a type of embedded plug-in that is not drawn on the screen when it is invoked. It is created by using the hidden attribute of the embed element. Here's an example:

<embed src="audiplay.aiff" type="audio/x-aiff" hidden="true">

NOTE: Whether a plug-in is windowed or windowless is not meaningful if the plug-in is invoked with the hidden attribute.

You can also create hidden plug-ins using the object element. Though the object element has no hidden attribute, you can create CSS rules to override the sizing attributes of the object element

object {
  visibility: visible;
}

object.hiddenObject {
  visibility:   hidden !important;
  width:        0px    !important;
  height:       0px    !important;
  margin:       0px    !important;
  padding:      0px    !important;
  border-style: none   !important;
  border-width: 0px    !important;
  max-width:    0px    !important;
  max-height:   0px    !important;
}

In this case, the object element that picks up these special style definitions would have a class of hidden. Using the class attribute and the CSS block above, you can simulate the behavior of the hidden plug-in in the embed element:

  <object data="audiplay.aiff" type="audio/x-aiff" class="hiddenObject"></object>


A full-page plug-in is a visible plug-in that is not part of an HTML page. The server looks for the media (MIME) type registered by a plug-in, based on the file extension, and starts sending the file to the browser. Gecko looks up the MIME type and loads the appropriate plug-in if it finds a plug-in registered to that type. This type of plug-in completely fills the web page. Full-page plug-ins are commonly used for document viewers, such as Adobe Acrobat.

NOTE: The browser does not display scroll bars automatically for a full-page plug-in. The plug-in must draw its own scroll bars if it requires them.

The browser user interface remains relatively constant regardless of which type of plug-in is displayed. The part of the application window that does not display plug-in data does not change. The basic operations of the browser, such as navigation, history, and opening files, apply to all pages, regardless of the plug-ins in use.

Using the object Element for Plug-in Display

The object element is part of the HTML specification for generic inclusion of special media in a web page. It embeds a variety of object types in an HTML page, including plug-ins, Java components, ActiveX controls, applets, and images. object element attributes determine the type of object to embed, the type and location of the object's implementation (code), and the type and implementation of the object's data.

Plug-ins were originally designed to work with the embed element rather than the object element (see Using the embed Element for Plug-in Display), but the object element itself provides some flexibility here. In particular, the object element allows you to invoke another object if the browser cannot support the object invoked by the element. The embed element, which is also used for plug-ins, does not.

The object element is also a part of the HTML W3C standard.

Also, unlike the applet element, object can contain other HTML elements including other object elements, nested between its opening and closing tags. So, for example, though Gecko does not support the classid attribute of the object element - which was used for Java classes and ActiveX plug-ins embedded in pages - object elements can be nested to support different plug-in implementations.

See the Mozilla ActiveX project page in the Plug-in References section below for more information about embedding ActiveX controls in plug-ins or embedding plug-ins in ActiveX applications.

The following examples demonstrate this use of nested object elements with markup more congenial to Gecko included as children of the parent object element.

Example 1: Nesting object Elements

<html>
<head>
<title>Example 1: Nesting object Elements</title>
<style type="text/css">
  .myPlugin {
     width:  470px;
     height: 231px;
  }
</style>
</head> 
<body><p>
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
        codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=5,0,30,0" 
        class="myPlugin">
 
  <param name="movie" value="foo.swf"/>
  <param name="quality" value="high"/>
  <param name="salign" value="tl"/>
  <param name="menu" value="0"/>
 
       <object data="foo_movie.swf"
               type="application/x-shockwave-flash"
               class="myPlugin"/>
 
         <param name="quality" value="high"/>
         <param name="salign" value="tl"/>
         <param name="menu" value="0"/>
 
          <object type="*" class="myPlugin">
            <param name="pluginspage" 
                   value="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash"/>
          </object>
 
       </object>
</object>
</p></body>
</html>

The outermost object element defines the classid; the first nested object uses the type value application/x-shockwave-flash to load the Adobe Flash plug-in, and the innermost object exposes a download page for users that do not already have the necessary plug-in. This nesting is quite common in the use of object elements, and lets you avoid code forking for different browser.

Nesting Rules for HTML Elements

The rules for descending into nested object and embed elements are as follows:

  • The browser looks at the MIME type of the top element. If it knows how to deal with that MIME type (i.e., by loading a plug-in that's been registered for it), then it does so.
  • If the browser cannot handle the MIME type, it looks in the element for a pointer to a plug-in that can be used to handle that MIME type. The browser downloads the requested plug-in.
  • If the MIME type is unknown and there is no reference to a plug-in that can be used, the browser descends into the child element, where these rules for handling MIME types are repeated.

The rest of this section is a brief introduction to this HTML element. For more information on the object element and other elements used for plug-in display, see W3C HTML 4.01 specification.

To embed a variety of object types in an HTML page, use the object element.

<object
  classid="classFile"
  data="dataLocation"
  codebase="classFileDir"
  type="MIMEtype"
  align="alignment" 
  height="pixHeight" 
  width="pixWidth"
  id="name"
 >

...

</object>

The first set of object element attributes are URLs.

  • classid is the URL of the specific object implementation. This attribute is similar to the code attribute of the applet element. Though Gecko does not support this object attribute, you can nest object elements with different attributes to use the object element for embedding plug-ins on any browser platform (see the example above).
  • data represents the URL of the object's data; this is equivalent to the src attribute of embed.
  • codebase represents the URL of the plug-in; this is the same as the codebase attribute of the applet element. For plug-ins, codebase is the same as pluginspace.
  • type represents the MIME type of the plug-in; this is the same as the type attribute of embed.
  • height, width, align are basic img/embed/applet attributes supported by object. height and width are required for object elements that resolve to embed elements.
  • Use the id attribute, which specifies the name of the plug-in, if the plug-in is communicating with JavaScript. This is equivalent to the name attribute of applet and embed. It must be unique.

Using the Appropriate Attributes

It's up to you to provide enough attributes and to make sure that they do not conflict; for example, the values of width and height may be wrong for the plug-in. Otherwise, the plug-in cannot be embedded.

Gecko interprets the attributes as follows: When the browser encounters an object element, it goes through the element attributes, ignoring or parsing as appropriate. It analyzes the attributes to determine the object type, then determines whether the browser can handle the type.

  • If the browser can handle the type-that is, if a plug-in exists for that type-then all elements and attributes up to the closing </object> element, except param elements and other object elements, are filtered.
  • If the browser cannot handle the type, or cannot determine the type, it cannot embed the object. Subsequent HTML is parsed as normal.

Using the embed Element for Plug-in Display

A plug-in runs in an HTML page in a browser window. The HTML author uses the HTML embed element to invoke the plug-in and control its display. Though the object element is the preferred way to invoke plug-ins (see Using the object Element for Plug-in Display), the embed element can be used for backward compatibility with Netscape 4.x browsers, and in cases where you specifically want to prompt the user to install a plug-in, because the default plug-in is only automatically invoked when you use the embed element.

Gecko loads an embedded plug-in when the user displays an HTML page that contains an embedded object whose MIME type is registered by a plug-in. Plug-ins are embedded in much the same way as GIF or JPEG images are, except that a plug-in can be live and respond to user events, such as mouse clicks.

The embed element has the following syntax and attributes:

<embed 
  src="location"
  type="mimetype"
  pluginspage="instrUrl"
  pluginurl="pluginUrl"
  align="left"|"right"|"top"|"bottom"
  border="borderWidth" 
  frameborder="no"
  height="height" 
  width="width"
  units="units"
  hidden="true|false"
  hspace="horizMargin" 
  vspace="vertMargin" 
  name="pluginName"
  palette="foreground"|"background"
 >
 
...
 
</embed>

You must include either the src attribute or the type attribute in an embed element. If you do not, then there is no way of determing the media type, and so no plug-in loads.

The src attribute is the URL of the file to run. The type attribute specifies the MIME type of the plug-in needed to run the file. Navigator uses either the value of the type attribute or the suffix of the filename given as the source to determine which plug-in to use.

Use type to specify the media type or MIME type necessary to display the plug-in. It is good practice to include the MIME type in all the plug-in HTML elements. You can use type for a plug-in that requires no data, for example, a plug-in that draws an analog clock or fetches all of its data dynamically. For a visible plug-in, you must include width and height if you use type; no default value is used.

The pluginurl attribute is the URL of the plug-in or of the XPI in which the plug-in is stored (see Installing Plug-ins for more information on the XPI file format).

The embed element has a number of attributes that determine the appearance and size of the plug-in instance, including these:

  • The border and frameborder attributes specify the size of a border for the plug-in or draw a borderless plug-in
  • height, width, and units determine the size of the plug-in in the HTML page. If the plug-in is not hidden, the height and width attributes are required.
  • hspace and vspace create a margin of the specified width, in pixels, around the plug-in.
  • align specifies the alignment for the plug-in relative to the web page.

Use the hidden attribute if you do not want the plug-in to be visible. In this case, you do not need the attributes that describe plug-in appearance. In fact, hidden overrides those attributes if they are present.

Use the name attribute, which specifies the name of the plug-in or plug-in instance, if the plug-in is communicating with JavaScript.

For example, this embed element loads a picture with the imaginary data type dgs.

<embed src="mypic.dgs" width="320" height="200" border="25" align="right">

Gecko interprets the attributes as follows:

  • src: Load the data file and determine the MIME type of the data.
  • width and height: Set the area of the page handled by the plug-in to 320 by 200 pixels. In general, use CSS to control the size and location of elements within an HTML page.
  • border: Draw a border 25 pixels wide around the plug-in.
  • align: Align the plug-in at the right side of the web page.

The following example shows an embed element nested within an object element, which latter is necessary for browsers that do not support the embed element.

Example 2: embed within object

<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" 
   codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=5,0,30,0" 
   width="749" height="68">

 <param name="movie" value="foo.swf">
 <param name="quality" value="high">
 <param name="bgcolor" value="#EEEEEE">
 <param name="salign" value="tl">
 <param name="menu" value="0">
 
 <embed src="foo.swf" 
   quality="high" pluginspage="http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash" 
   type="application/x-shockwave-flash" 
   width="749" 
   height="68" 
   bgcolor="#EEEEEE" 
   salign="tl" 
   menu="0">
 
 </embed>
 
</object>

Using Custom embed Attributes

In addition to these standard attributes, you can create private, plug-in-specific attributes and use them in the embed attribute to pass extra information between the HTML page and the plug-in code. The browser ignores these nonstandard attributes when parsing the HTML, but it passes all attributes to the plug-in, allowing the plug-in to examine the list for any private attributes that could modify its behavior.

For example, a plug-in that displays video could have private attributes that determine whether to start the plug-in automatically or loop the video automatically on playback, as in the following embed element:

<embed src="myavi.avi" width="100" height="125" autostart="true" loop="true">


With this embed element, Gecko passes the values to the plug-in, using the arg parameters of the NPP_New call that creates the plug-in instance.

argc = 5
argn = {"src", "width", "height", "autostart", "loop"}
argv = {"movie.avi", "100", "125", "true", "true"}

Gecko interprets the attributes as follows:

  • src: Load the data file and determine the MIME type of the data.
  • width and height: Set the area of the page handled by the plug-in to 100 by 125 pixels.
  • autostart and loop: Ignore these private attributes and pass them along to the plug-in with the rest of the attributes.

The plug-in must scan its list of attributes to determine whether it should automatically start the video and loop it on playback. Note that with an object element, param values are also sent in this array after the attributes, separated by a param entry.

Plug-in References

Pièces jointes

Fichier Taille Date Joint par
plugin_puzzle.gif
2239 octets 2005-08-12 18:01:39 Emil
Using_Remote_Xul_Step3.png
42452 octets 2005-11-30 04:18:00 Andreas Wuest

Étiquettes et contributeurs liés au document

Contributeurs ayant participé à cette page : Demos
Dernière mise à jour par : Demos,