16. XHTML Object Module

Contents

This section is normative.

The Object Module provides elements for general-purpose object inclusion; this includes images and other media, as well as executable content. Specifically, the Object Module supports:

Elements Attributes Minimal Content Model
object Common, archive (URIs), classid (URI), codebase (URI), content-length (MultiLength) codetype (ContentType), data (URI), disabled ("disabled"), declare ("declare"), standby (Text), navindex (Number), type (ContentType) (PCDATA | Flow | param)*
param id (ID), name* (CDATA), type (ContentType), value (CDATA), valuetype ("data"* | "ref" | "object") EMPTY

When this module is used, it adds the object element to the Inline content set of the Text Module.

Implementation: DTD

16.1. The object element

Attributes

The Common collection
A collection of other attribute collections, including: Core, Events, I18N, and Hypertext
archive = URI List
This attribute specifies a comma-separated list of URIs for archives containing classes and other resources that will be "preloaded". The classes are loaded using an instance of an AppletClassLoader with the given codebase. Relative URIs for archives are interpreted with respect to the applet's codebase. Preloading resources can significantly improve the performance of applets.
classid = URI
This attribute may be used to specify the location of an object's implementation via a URI. It may be used together with, or as an alternative to the data attribute, depending on the type of object involved.
codebase = URI
This attribute specifies the base URI for the applet. If this attribute is not specified, then it defaults the same base URI as for the current document. Values for this attribute may only refer to subdirectories of the directory containing the current document.
codetype = ContentType
This attribute specifies the content type of data expected when downloading the object specified by classid. This attribute is optional but recommended when classid is specified since it allows the user agent to avoid loading information for unsupported content types. When absent, it defaults to the value of the type attribute.
data = URI
This attribute may be used to specify the location of the object's data, for instance image data for objects defining images, or more generally, a serialized form of an object which can be used to recreate it. If given as a relative URI, it should be interpreted relative to the codebase attribute.
declare = "declare"
When present, this boolean attribute makes the current object element a declaration only - not one that is to be executed until after the document has completed loading.
disabled = "disabled"
When present, this boolean attribute makes the current object not availale as an input element when used in conjunction with an input form.
standby = Text
This attribute specifies a message that a user agent may render while loading the object's implementation and data.
navindex = Number
This attribute specifies the position of the current element in the navingation order for the current document. This value must be a number between 0 and 32767. User agents must ignore leading zeros.

The navigation order defines the order in which elements will receive focus when navigated by the user via the keyboard. The navigation order may include elements nested within other elements.

Elements that may receive focus should be navigated by user agents according to the following rules:

  1. Those elements that support the navindex attribute and assign a positive value to it are navigated first. Navigation proceeds from the element with the lowest navindex value to the element with the highest value. Values need not be sequential nor must they begin with any particular value. Elements that have identical navindex values should be navigated in the order they appear in the character stream.
  2. Those elements that do not support the navindex attribute or support it and assign it a value of "0" are navigated next. These elements are navigated in the order they appear in the character stream.
  3. Elements that are disabled do not participate in the navigation order.

Tabbing keys. The actual key sequence that causes navigation or element activation depends on the configuration of the user agent (e.g., the "tab" key is used for navigation and the "enter" key is used to activate a selected element).

User agents may also define key sequences to navigate the navigation order in reverse. When the end (or beginning) of the navigation order is reached, user agents may circle back to the beginning (or end).

type = ContentType
This attribute gives an advisory hint as to the content type of the content available at the link target address. It allows user agents to opt to use a fallback mechanism rather than fetch the content if they are advised that they will get content in a content type they do not support.

Authors who use this attribute take responsibility to manage the risk that it may become inconsistent with the content available at the link target address.

For the current list of registered content types, please consult [MIMETYPES].

Most user agents have built-in mechanisms for processing common data types such as text, GIF images, colors, fonts, and a handful of graphic elements. To process data types they don't support natively, user agents generally run external applications. The object element allows authors to control whether data should be processed externally or by some program, specified by the author, that processes the data within the user agent.

In the most general case, an author may need to specify three types of information:

The object element allows authors to specify all three types of data, but authors may not have to specify all three at once. For example, some objects may not require data (e.g., a self-contained applet that performs a small animation). Others may not require run-time initialization. Still others may not require additional implementation information, i.e., the user agent itself may already know how to process that type of data (e.g., GIF images).

Authors specify an object's implementation and the location of the data to be processed via the object element. To specify run-time values, however, authors use the param element, which is discussed in the section on object initialization.

The object element may also appear in the content of the head element. Since user agents generally do not process elements in the head, authors should ensure that any object elements in the head do not specify content that may be processed. Please consult the section on sharing frame data for an example of including the object element in the head element.

Please consult the section on form controls for information about object elements in forms.

This document does not specify the behavior of object elements that use both the classid attribute to identify an implementation and the data attribute to specify data for that implementation. In order to ensure portability, authors should use the param element to tell implementations where to retrieve additional data.

16.1.1. Rules for processing objects

A user agent must interpret an object element according to the following precedence rules:

  1. The user agent must first try to process the object. It should not process the element's contents, but it must examine them in case the element contains any direct children that are param elements (see object initialization) or map elements (see client-side image maps).
  2. If the user agent is not able to process the object for whatever reason (configured not to, lack of resources, wrong architecture, etc.), it must try to process its contents.

Authors should not include content in object elements that appear in the head element.

In the following example, we insert an analog clock applet in a document via the object element. The applet, written in the Python language, requires no additional data or run-time values. The classid attribute specifies the location of the applet:

    
<object classid="http://www.miamachina.it/analogclock.py">
</object>

Note that the clock will be processed as soon as the user agent interprets this object declaration. It is possible to delay processing of an object by first declaring the object (described below).

Authors should complete this declaration by including alternate text as the contents of object in case the user agent cannot process the clock.

    
<p><object classid="http://www.miamachina.it/analogclock.py">
An animated clock.
</object>

One significant consequence of the object element's design is that it offers a mechanism for specifying alternate object processing; each embedded object declaration may specify alternate content types. If a user agent cannot process the outermost object, it tries to process the contents, which may be another object element, etc.

In the following example, we embed several object declarations to illustrate how alternate processing work. A user agent will attempt to process the first object element it can, in the following order: (1) an Earth applet written in the Python language, (2) an MPEG animation of the Earth, (3) a GIF image of the Earth, (4) alternate text.

<p>                 <!-- First, try the Python applet -->
<object title="The Earth as seen from space" 
        classid="http://www.observer.mars/TheEarth.py">
                    <!-- Else, try the MPEG video -->
  <object data="TheEarth.mpeg" type="application/mpeg">
                    <!-- Else, try the GIF image -->
    <object data="TheEarth.gif" type="image/gif">
                    <!-- Else render the text -->
     The <strong>Earth</strong> as seen from space.
    </object>
  </object>
</object>

The outermost declaration specifies an applet that requires no data or initial values. The second declaration specifies an MPEG animation and, since it does not define the location of an implementation to handle MPEG, relies on the user agent to handle the animation. We also set the type attribute so that a user agent that knows it cannot process an MPEG will not bother to retrieve "TheEarth.mpeg" from the network. The third declaration specifies the location of a GIF file and furnishes alternate text in case all other mechanisms fail.

Inline vs. external data. Data to be processed may be supplied in two ways: inline and from an external resource. While the former method will generally lead to faster processing, it is not convenient when processing large quantities of data.

Here's an example that illustrates how inline data may be fed to an object:

<p>
<object id="clock1"
        classid="clsid:663C8FEF-1EF9-11CF-A3DB-080036F12502"
        data="data:application/x-oleobject;base64, ...base64 data...">
    A clock.
</object>

16.2. The param element.

Attributes

name = CDATA
This attribute defines the name of a run-time parameter, assumed to be known by the inserted object. Whether the property name is case-sensitive depends on the specific object implementation.
value = CDATA
This attribute specifies the value of a run-time parameter specified by name. Property values have no meaning to HTML; their meaning is determined by the object in question.
valuetype = data|ref|object
This attribute specifies the type of the value attribute.

Possible values:

  • data: This is default value for the attribute. It means that the value specified by value will be evaluated and passed to the object's implementation as a string.
  • ref: The value specified by value is a URI that designates a resource where run-time values are stored. This allows support tools to identify URIs given as parameters. The URI must be passed to the object as is, i.e., unresolved.
  • object: The value specified by value is an identifier that refers to an object declaration in the same document. The identifier must be the value of the id attribute set for the declared object element.
type = ContentType
This attribute specifies the content type of the resource designated by the value attribute only in the case where valuetype is set to "ref". This attribute thus specifies for the user agent, the type of values that will be found at the URI designated by value.

param elements specify a set of values that may be required by an object at run-time. Any number of param elements may appear in the content of an object element, in any order, but must be placed at the start of the content of the enclosing object element.

The syntax of names and values is assumed to be understood by the object's implementation. This document does not specify how user agents should retrieve name/value pairs nor how they should interpret parameter names that appear twice.

We return to the clock example to illustrate the use of param: suppose that the applet is able to handle two run-time parameters that define its initial height and width. We can set the initial dimensions to 40x40 pixels with two param.

    
<p><object classid="http://www.miamachina.it/analogclock.py">
<param name="height" value="40" valuetype="data" />
<param name="width" value="40" valuetype="data" />
This user agent cannot render Python applications.
</object>

In the following example, run-time data for the object's "Init_values" parameter is specified as an external resource (a GIF file). The value of the valuetype attribute is thus set to "ref" and the value is a URI designating the resource.

<p><object classid="http://www.gifstuff.com/gifappli"
       standby="Loading Elvis...">
<param name="Init_values"
       value="./images/elvis.gif"
       valuetype="ref" />
</object>
</p>

Note that we have also set the standby attribute so that the user agent may display a message while the rendering mechanism loads.

When an object element is rendered, user agents must search the content for only those param elements that are direct children and "feed" them to the object.

Thus, in the following example, if "obj1" is rendered, "param1" applies to "obj1" (and not "obj2"). If "obj1" is not rendered and "obj2" is, "param1" is ignored, and "param2" applies to "obj2". If neither object is rendered, neither param applies.

<p>
<object id="obj1">
   <param name="param1">
   <object id="obj2">
      <param name="param2">
   </object>
</object>

16.2.1. Global naming schemes for objects

The location of an object's implementation is given by a URI. The first segment of an absolute URI specifies the naming scheme used to transfer the data designated by the URI. For XHTML documents, this scheme is frequently "http". Some applets might employ other naming schemes. For instance, when specifying a Java applet, authors may use URIs that begin with "java" and for ActiveX applets, authors may use "clsid".

In the following example, we insert a Java applet into an XHTML document.

<p><object classid="java:program.start">
</object>

By setting the codetype attribute, a user agent can decide whether to retrieve the Java application based on its ability to do so.

<object codetype="application/java-archive"
        classid="java:program.start">
</object>

Some rendering schemes require additional information to identify their implementation and must be told where to find that information. Authors may give path information to the object's implementation via the codebase attribute.

<object codetype="application/java-archive"
        classid="java:program.start">
        codebase="http://foooo.bar.com/java/myimplementation/"
</object>

The following example specifies (with the classid attribute) an ActiveX object via a URI that begins with the naming scheme "clsid". The data attribute locates the data to render (another clock).

<p><object classid="clsid:663C8FEF-1EF9-11CF-A3DB-080036F12502"
        data="http://www.acme.com/ole/clock.stm">
This application is not supported.
</object>

16.2.2. Object declarations and instantiations

The preceding examples have only illustrated isolated object definitions. When a document is to contain more than one instance of the same object, it is possible to separate the declaration of the object from its instantiations. Doing so has several advantages:

To declare an object so that it is not executed when read by the user agent, set the boolean declare attribute in the object element. At the same time, authors must identify the declaration by setting the id attribute in the object element to a unique value. Later instantiations of the object will refer to this identifier.

A declared object must appear in a document before the first instance of that object.

An object defined with the declare attribute is instantiated every time an element that refers to that object requires it to be rendered (e.g., a link that refers to it is activated, an object that refers to it is activated, etc.).

In the following example, we declare an object and cause it to be instantiated by referring to it from a link. Thus, the object can be activated by clicking on some highlighted text, for example.

<p><object declare
        id="earth.declaration" 
        data="TheEarth.mpeg" 
        type="application/mpeg">
   The <strong>Earth</strong> as seen from space.
</object>
...later in the document...
<p>A neat <A href="#earth.declaration"> animation of The Earth!</A>

The following example illustrates how to specify run-time values that are other objects. In this example, we send text (a poem, in fact) to a hypothetical mechanism for viewing poems. The object recognizes a run-time parameter named "font" (say, for rendering the poem text in a certain font). The value for this parameter is itself an object that inserts (but does not render) the font object. The relationship between the font object and the poem viewer object is achieved by (1) assigning the id "tribune" to the font object declaration and (2) referring to it from the param element of the poem viewer object (with valuetype and value).

<p><object declare
     id="tribune"
     type="application/x-webfont"
     data="tribune.gif">
</object>
...view the poem in KublaKhan.txt here...
<p><object classid="http://foo.bar.com/poem_viewer" 
           data="KublaKhan.txt">
<param name="font" valuetype="object" value="#tribune">
<p>You're missing a really cool poem viewer ...
</object>

User agents that don't support the declare attribute must render the contents of the object declaration.