# 13 Objects, Images, and Applets

Contents

1. Introduction to objects, images, and applets
2. Including an image: the `IMG` element
3. Generic inclusion: the `OBJECT` element
   1. Rules for rendering objects
   2. Object initialization: the `PARAM` element
   3. Global naming schemes for objects
   4. Object declarations and instantiations
4. Including an applet: the `APPLET` element
5. Notes on embedded documents
6. Image maps
   1. Client-side image maps: the `MAP` and `AREA` elements
      - Client-side image map examples
   2. Server-side image maps
7. Visual presentation of images, objects, and applets
   1. Width and height
   2. White space around images and objects
   3. Borders
   4. Alignment
8. How to specify alternate text

## 13.1 Introduction to objects, images, and applets

HTML's multimedia features allow authors to include images, applets (programs that are automatically downloaded and run on the user's machine), video clips, and other HTML documents in their pages.

For example, to include a PNG image in a document, authors may write:

    <BODY>
    <P>Here's a closeup of the Grand Canyon:
    <OBJECT data="canyon.png" type="image/png">
    This is a <EM>closeup</EM> of the Grand Canyon.
    </OBJECT>
    </BODY>

Previous versions of HTML allowed authors to include images (via `IMG`) and applets (via `APPLET`). These elements have several limitations:

- They fail to solve the more general problem of how to include new and future media types.
- The `APPLET` element only works with Java-based applets. This element is deprecated in favor of `OBJECT`.
- They pose accessibility problems.

To address these issues, HTML 4.0 introduces the `OBJECT` element, which offers an all-purpose solution to generic object inclusion. The `OBJECT` element allows HTML authors to specify everything required by an object for its presentation by a user agent: source code, initial values, and run-time data. In this specification, the term "object" is used to describe the things that people want to place in HTML documents; other commonly used terms for these things are: applets, plug-ins, media handlers, etc.

The new `OBJECT` element thus subsumes some of the tasks carried out by existing elements. Consider the following chart of functionalities:

Type of inclusion | Specific element | Generic element
--- | --- | ---
Image | `IMG` | `OBJECT`
Applet | `APPLET` (Deprecated.) | `OBJECT`
Another HTML document | `IFRAME` | `OBJECT`

The chart indicates that each type of inclusion has a specific and a general solution. The generic `OBJECT` element will serve as the solution for implementing future media types.

To include images, authors may use the `OBJECT` element or the `IMG` element.

To include applets, authors should use the `OBJECT` element as the `APPLET` element is deprecated.

To include one HTML document in another, authors may use either the new `IFRAME` element or the `OBJECT` element. In both cases, the embedded document remains independent of the main document. Visual user agents may present the embedded document in a distinct window within the main document. Please consult the notes on embedded documents for a comparison of `OBJECT` and `IFRAME` for document inclusion.

Images and other included objects may have hyperlinks associated with them, both through the standard linking mechanisms, but also via image maps. An image map specifies active geometric regions of an included object and assigns a link to each region. When activated, these links may cause a document to be retrieved, may run a program on the server, etc.

In the following sections, we discuss the various mechanisms available to authors for multimedia inclusions and creating image maps for those inclusions.

## 13.2 Including an image: the `IMG` element

    <!-- To avoid problems with text-only UAs as well as
       to make image content understandable and navigable
       to users of non-visual UAs, you need to provide
       a description with ALT, and avoid server-side image maps -->
    <!ELEMENT IMG - O EMPTY                -- Embedded image -->
    <!ATTLIST IMG
      %attrs;                              -- %coreattrs, %i18n, %events --
      src         %URI;          #REQUIRED -- URI of image to embed --
      alt         %Text;         #REQUIRED -- short description --
      longdesc    %URI;          #IMPLIED  -- link to long description
                                              (complements alt) --
      height      %Length;       #IMPLIED  -- override height --
      width       %Length;       #IMPLIED  -- override width --
      usemap      %URI;          #IMPLIED  -- use client-side image map --
      ismap       (ismap)        #IMPLIED  -- use server-side image map --
      >

Start tag: required, End tag: forbidden

Attribute definitions

`src` = uri [CT]
  This attribute specifies the location of the image resource. Examples of widely recognized image formats include GIF, JPEG, and PNG.
`longdesc` = uri [CT]
  This attribute specifies a link to a long description of the image. This description should supplement the short description provided using the `alt` attribute. When the image has an associated image map, this attribute should provide information about the image map's contents. This is particularly important for server-side image maps.

Attributes defined elsewhere

- `id`, `class` (document-wide identifiers)
- `alt` (alternate text)
- `lang` (language information), `dir` (text direction)
- `title` (element title)
- `style` (inline style information)
- `onclick`, `ondblclick`, `onmousedown`, `onmouseup`, `onmouseover`, `onmousemove`, `onmouseout`, `onkeypress`, `onkeydown`, `onkeyup` (intrinsic events)
- `ismap`, `usemap` (client side image maps)
- `align`, `width`, `height`, `border`, `hspace`, `vspace` (visual presentation of objects, images, and applets)

The `IMG` element embeds an image in the current document at the location of the element's definition. The `IMG` element has no content; it is usually replaced inline by the image designated by the `src` attribute, the exception being for left or right-aligned images that are "floated" out of line.

In an earlier example, we defined a link to a family photo. Here, we insert the photo directly into the current document:

    <BODY>
    <P>I just returned from vacation! Here's a photo of my family at the lake:
    <IMG src="http://www.somecompany.com/People/Ian/vacation/family.png"
         alt="A photo of my family at the lake.">
    </BODY>

This inclusion may also be achieved with the `OBJECT` element as follows:

    <BODY>
    <P>I just returned from vacation! Here's a photo of my family at the lake:
    <OBJECT data="http://www.somecompany.com/People/Ian/vacation/family.png"
            type="image/png">
    A photo of my family at the lake.
    </OBJECT>
    </BODY>

The `alt` attribute specifies alternate text that is rendered when the image cannot be displayed (see below for information on how to specify alternate text ). User agents must render alternate text when they cannot support images, they cannot support a certain image type or when they are configured not to display images.

The following example shows how the `longdesc` attribute can be used to link to a richer description:

    <BODY>
    <P>
    <IMG src="sitemap.gif"
         alt="HP Labs Site Map"
         longdesc="sitemap.html">
    </BODY>

The `alt` attribute provides a short description of the image. This should be sufficient to allow users to decide whether they want to follow the link given by the `longdesc` attribute to the longer description, here "sitemap.html".

Please consult the section on the visual presentation of objects, images, and applets for information about image size, alignment, and borders.

## 13.3 Generic inclusion: the `OBJECT` element

    <!ELEMENT OBJECT - - (PARAM | %flow;)*
     -- generic embedded object -->
    <!ATTLIST OBJECT
      %attrs;                              -- %coreattrs, %i18n, %events --
      declare     (declare)      #IMPLIED  -- declare but don't instantiate flag --
      classid     %URI;          #IMPLIED  -- identifies an implementation --
      codebase    %URI;          #IMPLIED  -- base URI for classid, data, archive--
      data        %URI;          #IMPLIED  -- reference to object's data --
      type        %ContentType;  #IMPLIED  -- content type for data --
      codetype    %ContentType;  #IMPLIED  -- content type for code --
      archive     %URI;          #IMPLIED  -- space separated archive list --
      standby     %Text;         #IMPLIED  -- message to show while loading --
      height      %Length;       #IMPLIED  -- override height --
      width       %Length;       #IMPLIED  -- override width --
      usemap      %URI;          #IMPLIED  -- use client-side image map --
      name        CDATA          #IMPLIED  -- submit as part of form --
      tabindex    NUMBER         #IMPLIED  -- position in tabbing order --
      >

Start tag: required, End tag: required

Attribute definitions

`classid` = uri [CT]
  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 [CT]
  This attribute specifies the base path used to resolve relative URIs specified by the `classid`, `data`, and `archive` attributes. When absent, its default value is the base URI of the current document.
`codetype` = content-type [CI]
  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 [CT]
  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.
`type` = content-type [CI]
  This attribute specifies the content type for the data specified by `data`. This attribute is optional but recommended when `data` is specified since it allows the user agent to avoid loading information for unsupported content types.
`archive` = uri list [CT]
  This attribute may be used to specify a space-separated list of URIs for archives containing resources relevant to the object, which may include the resources specified by the `classid` and `data` attributes. Preloading archives will generally result in reduced load times for objects. Archives specified as relative URIs should be interpreted relative to the `codebase` attribute.
`declare` [CI]
  When present, this boolean attribute makes the current `OBJECT` definition a declaration only. The object must be instantiated by a subsequent `OBJECT` definition referring to this declaration.
`standby` = text [CS]
  This attribute specifies a message that a user agent may render while loading the object's implementation and data.

Attributes defined elsewhere

- `id`, `class` (document-wide identifiers)
- `lang` (language information), `dir` (text direction)
- `title` (element title)
- `style` (inline style information)
- `onclick`, `ondblclick`, `onmousedown`, `onmouseup`, `onmouseover`, `onmousemove`, `onmouseout`, `onkeypress`, `onkeydown`, `onkeyup` (intrinsic events)
- `tabindex` (tabbing navigation)
- `usemap` (client side image maps)
- `name` (form submission)
- `align`, `width`, `height`, `border`, `hspace`, `vspace` (visual presentation of objects, images, and applets)

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

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

- The implementation of the included object. For instance, if the included object is a clock applet, the author must indicate the location of the applet's executable code.
- The data to be rendered. For instance, if the included object is a program that renders font data, the author must indicate the location of that data.
- Additional values required by the object at run-time. For example, some applets may require initial values for parameters.

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 render that type of data (e.g., GIF images).

Authors specify an object's implementation and the location of the data to be rendered 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 render elements in the `HEAD`, authors should ensure that any `OBJECT` elements in the `HEAD` do not specify content that may be rendered. 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.

### 13.3.1 Rules for rendering objects

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

1. The user agent must first try to render the object. It should not render 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 render the object for whatever reason (configured not to, lack of resources, wrong architecture, etc.), it must try to render 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:

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

Note that the clock will be rendered as soon as the user agent interprets this `OBJECT` declaration. It is possible to delay rendering 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 render 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 renderings; each embedded `OBJECT` declaration may specify alternate content types. If a user agent cannot render the outermost `OBJECT`, it tries to render the contents, which may be another `OBJECT` element, etc.

In the following example, we embed several `OBJECT` declarations to illustrate how alternate renderings work. A user agent will attempt to render 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 render 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 rendered may be supplied in two ways: inline and from an external resource. While the former method will generally lead to faster rendering, it is not convenient when rendering 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>

Please consult the section on the visual presentation of objects, images, and applets for information about object size, alignment, and borders.

### 13.3.2 Object initialization: the `PARAM` element

    <!ELEMENT PARAM - O EMPTY              -- named property value -->
    <!ATTLIST PARAM
      id          ID             #IMPLIED  -- document-wide unique id --
      name        CDATA          #REQUIRED -- property name --
      value       CDATA          #IMPLIED  -- property value --
      valuetype   (DATA|REF|OBJECT) DATA   -- How to interpret value --
      type        %ContentType;  #IMPLIED  -- content type for value
                                              when valuetype=ref --
      >

Start tag: required, End tag: forbidden

Attribute definitions

`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` [CI]
  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` = content-type [CI]
  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`.

Attributes defined elsewhere

- `id` (document-wide identifiers)

`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` or `APPLET` element, in any order, but must be placed at the start of the content of the enclosing `OBJECT` or `APPLET` 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` elements.

    <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>

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>

### 13.3.3 Global naming schemes for objects

The location of an object's implementation is given by a URI. As we discussed in the introduction to URIs, the first segment of an absolute URI specifies the naming scheme used to transfer the data designated by the URI. For HTML 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 HTML 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>

### 13.3.4 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:

- Data may be retrieved from the network by the user agent one time (during the declaration) and reused for each instantiation.
- It is possible to instantiate an object from a location other than the object's declaration, for example, from a link.
- It is possible to specify objects as run-time data for other objects.

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 so 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.

## 13.4 Including an applet: the `APPLET` element

APPLET is deprecated (with all its attributes) in favor of `OBJECT`.

See the Transitional DTD for the formal definition.

Attribute definitions

`codebase` = uri [CT]
  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.
`code` = cdata [CS]
  This attribute specifies either the name of the class file that contains the applet's compiled applet subclass or the path to get the class, including the class file itself. It is interpreted with respect to the applet's codebase. One of `code` or `object` must be present.
`name` = cdata [CS]
  This attribute specifies a name for the applet instance, which makes it possible for applets on the same page to find (and communicate with) each other.
`archive` = uri-list [CT]
  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.
`object` = cdata [CS]
  This attribute names a resource containing a serialized representation of an applet's state. It is interpreted relative to the applet's codebase. The serialized data contains the applet's class name but not the implementation. The class name is used to retrieve the implementation from a class file or archive.

  When the applet is "deserialized" the `start()` method is invoked but not the `init()` method. Attributes valid when the original object was serialized are not restored. Any attributes passed to this `APPLET` instance will be available to the applet. Authors should use this feature with extreme caution. An applet should be stopped before it is serialized.

  Either `code` or `object` must be present. If both `code` and `object` are given, it is an error if they provide different class names.

`width` = length [CI]
  This attribute specifies the initial width of the applet's display area (excluding any windows or dialogs that the applet creates).
`height` = length [CI]
  This attribute specifies the initial height of the applet's display area (excluding any windows or dialogs that the applet creates).

Attributes defined elsewhere

- `id`, `class` (document-wide identifiers)
- `title` (element title)
- `style` (inline style information)
- `alt` (alternate text)
- `align`, `hspace`, `vspace` (visual presentation of objects, images, and applets)

This element, supported by all Java-enabled browsers, allows designers to embed a Java applet in an HTML document. It has been deprecated in favor of the `OBJECT` element.

The content of the `APPLET` acts as alternate information for user agents that don't support this element or are currently configured not to support applets. User agents must ignore the content otherwise.

DEPRECATED EXAMPLE:
In the following example, the `APPLET` element includes a Java applet in the document. Since no `codebase` is supplied, the applet is assumed to be in the same directory as the current document.

    <APPLET code="Bubbles.class" width="500" height="500">
    Java applet that draws animated bubbles.
    </APPLET>

This example may be rewritten as follows with `OBJECT` as follows:

    <P><OBJECT codetype="application/java"
            classid="java:Bubbles.class"
            width="500" height="500">
    Java applet that draws animated bubbles.
    </OBJECT>

Initial values may be supplied to the applet via the `PARAM` element.

DEPRECATED EXAMPLE:
The following sample Java applet:

    <APPLET code="AudioItem" width="15" height="15">
    <PARAM name="snd" value="Hello.au|Welcome.au">
    Java applet that plays a welcoming sound.
    </APPLET>

may be rewritten as follows with `OBJECT`:

    <OBJECT codetype="application/java"
            classid="AudioItem"
            width="15" height="15">
    <PARAM name="snd" value="Hello.au|Welcome.au">
    Java applet that plays a welcoming sound.
    </OBJECT>

## 13.5 Notes on embedded documents

Sometimes, rather than linking to a document, an author may want to embed it directly into a primary HTML document. Authors may use either the `IFRAME` element or the `OBJECT` element for this purpose, but the elements differ in some ways. Not only do the two elements have different content models, the `IFRAME` element may be a target frame (see the section on specifying target frame information for details) and may be "selected" by a user agent as the focus for printing, viewing HTML source, etc. User agents may render selected frames elements in ways that distinguish them from unselected frames (e.g., by drawing a border around the selected frame).

An embedded document is entirely independent of the document in which it is embedded. For instance, relative URIs within the embedded document resolve according to the base URI of the embedded document, not that of the main document. An embedded document is only rendered within another document (e.g., in a subwindow); it remains otherwise independent.

For instance, the following line embeds the contents of `embed_me.html` at the location where the `OBJECT` definition occurs.

    ...text before...
    <OBJECT data="embed_me.html">
    Warning: embed_me.html could not be embedded.
    </OBJECT>
    ...text after...

Recall that the contents of `OBJECT` must only be rendered if the file specified by the `data` attribute cannot be loaded.

The behavior of a user agent in cases where a file includes itself is not defined.

## 13.6 Image maps

Image maps allow authors to specify regions of an image or object and assign a specific action to each region (e.g., retrieve a document, run a program, etc.) When the region is activated by the user, the action is executed.

An image map is created by associating an object with a specification of sensitive geometric areas on the object.

There are two types of image maps:

- Client-side. When a user activates a region of a client-side image map with a mouse, the pixel coordinates are interpreted by the user agent. The user agent selects a link that was specified for the activated region and follows it.
- Server-side. When a user activates a region of a server-side image map with a mouse, the pixel coordinates of the click are sent to the server-side agent specified by the `href` attribute of the `A` element. The server-side agent interprets the coordinates and performs some action.

Client-side image maps are preferred over server-side image maps for at least two reasons: they are accessible to people browsing with non-graphical user agents and they offer immediate feedback as to whether or not the pointer is over an active region.

### 13.6.1 Client-side image maps: the `MAP` and `AREA` elements

    <!ELEMENT MAP - - ((%block;)+ | AREA+) -- client-side image map -->
    <!ATTLIST MAP
      %attrs;                              -- %coreattrs, %i18n, %events --
      name        CDATA          #REQUIRED -- for reference by usemap --
      >

Start tag: required, End tag: required

    <!ELEMENT AREA - O EMPTY               -- client-side image map area -->
    <!ATTLIST AREA
      %attrs;                              -- %coreattrs, %i18n, %events --
      shape       %Shape;        rect      -- controls interpretation of coords --
      coords      %Coords;       #IMPLIED  -- comma separated list of lengths --
      href        %URI;          #IMPLIED  -- URI for linked resource --
      nohref      (nohref)       #IMPLIED  -- this region has no action --
      alt         %Text;         #REQUIRED -- short description --
      tabindex    NUMBER         #IMPLIED  -- position in tabbing order --
      accesskey   %Character;    #IMPLIED  -- accessibility key character --
      onfocus     %Script;       #IMPLIED  -- the element got the focus --
      onblur      %Script;       #IMPLIED  -- the element lost the focus --
      >

Start tag: required, End tag: forbidden

MAP attribute definitions

`name` = cdata [CI]
  This attribute assigns a name to the image map defined by a `MAP` element.

AREA attribute definitions

`shape` = `default|rect|circle|poly` [CI]
  This attribute specifies the shape of a region. Possible values:
  - `default:` Specifies the entire region.
  - `rect:` Define a rectangular region.
  - `circle:` Define a circular region.
  - `poly:` Define a polygonal region.
`coords` = coordinates [CN]
  This attribute specifies the position a shape on the screen. The number and order of values depends on the shape being defined. Possible combinations:
  - `rect:` left-x, top-y, right-x, bottom-y.
  - `circle:` center-x, center-y, radius. Note. When the radius value is a percentage value, user agents should calculate the final radius value based on the associated object's width and height. The radius should be the smaller value of the two.
  - `poly:` x1, y1, x2, y2, ..., xN, yN.

  Coordinates are relative to the top, left corner of the object. All values are lengths. All values are separated by commas.

`nohref` [CI]
  When set, this boolean attribute specifies that a region has no associated link.

Attribute to associate an image map with an element

`usemap` = uri [CT]
  This attribute associates an image map with an element. The image map is defined by a `MAP` element. The value of `usemap` must match the value of the `name` attribute of the associated `MAP` element.

Attributes defined elsewhere

- `id`, `class` (document-wide identifiers)
- `lang` (language information), `dir` (text direction)
- `title` (element title)
- `style` (inline style information)
- `name` (submitting objects with forms)
- `alt` (alternate text)
- `href` ( anchor reference) `target` (frame target information)
- `tabindex` (tabbing navigation)
- `accesskey` (access keys)
- `shape` (image maps)
- `onclick`, `ondblclick`, `onmousedown`, `onmouseup`, `onmouseover`, `onmousemove`, `onmouseout`, `onkeypress`, `onkeydown`, `onkeyup`, `onfocus`, `onblur` (intrinsic events)

The `MAP` element specifies a client-side image map that may be associated with one or more elements (`IMG`, `OBJECT`, or `INPUT`). An image map is associated with an element via the element's `usemap` attribute.

The presence of the `usemap` attribute for an `OBJECT` implies that the object being included is an image. Furthermore, when the `OBJECT` element has an associated client-side image map, user agents may implement user interaction with the `OBJECT` solely in terms of the client-side image map. This allows user agents (such as an audio browser or robot) to interact with the `OBJECT` without having to process it; the user agent may even elect not to retrieve (or process) the object. When an `OBJECT` has an associated image map, authors should not expect that the object will be retrieved or processed by every user agent.

Each `MAP` element may contain either one of the following:

1. One or more `AREA` elements. These elements have no content but specify the geometric regions of the image map and the link associated with each region. Note that when this method is used, the `MAP` has no rendered content. Therefore, authors must provide alternate text for each `AREA` with the `alt` attribute (see below for information on how to specify alternate text).
2. Block-level content. This content should include `A` elements that specify the geometric regions of the image map and the link associated with each region. Note that when this method is used, the `MAP` element content may be rendered by the user agent. Authors should use this method to create more accessible documents.

If two or more defined regions overlap, the region-defining element that appears earliest in the document takes precedence (i.e., responds to user input).

User agents and authors should offer textual alternates to graphical image maps for cases when graphics are not available or the user cannot access them. For example, user agents may use `alt` text to create textual links in place of a graphical image map. Such links may be activated in a variety of ways (keyboard, voice activation, etc.).

Note. `MAP` is not backwards compatible with HTML 2.0 user agents.

#### Client-side image map examples

In the following example, we create a client-side image map for the `OBJECT` element. We do not want to render the image map's contents when the `OBJECT` is rendered, so we "hide" the `MAP` element within the `OBJECT` element's content. Consequently, the `MAP` element's contents will only be rendered if the `OBJECT` cannot be rendered.

    <HTML>
       <HEAD>
          <TITLE>The cool site!</TITLE>
       </HEAD>
       <BODY>
         <P><OBJECT data="navbar1.gif" type="image/gif" usemap="#map1">
         <MAP name="map1">
           <P>Navigate the site:
           <A href="guide.html" shape="rect" coords="0,0,118,28">Access Guide</a> |
           <A href="shortcut.html" shape="rect" coords="118,0,184,28">Go</A> |
           <A href="search.html" shape="circle" coords="184,200,60">Search</A> |
           <A href="top10.html" shape="poly" coords="276,0,373,28,50,50,100,120">Top Ten</A><
         </MAP>
         </OBJECT>
       </BODY>
    </HTML>

We may want to render the image map's contents even when a user agent can render the `OBJECT`. For instance, we may want to associate an image map with an `OBJECT` element and include a text navigation bar at the bottom of the page. To do so, we define the `MAP` element outside the `OBJECT`:

    <HTML>
       <HEAD>
          <TITLE>The cool site!</TITLE>
       </HEAD>
       <BODY>
         <P><OBJECT data="navbar1.gif" type="image/gif" usemap="#map1">
         </OBJECT>

         ...the rest of the page here...

         <MAP name="map1">
           <P>Navigate the site:
           <A href="guide.html" shape="rect" coords="0,0,118,28">Access Guide</a> |
           <A href="shortcut.html" shape="rect" coords="118,0,184,28">Go</A> |
           <A href="search.html" shape="circle" coords="184,200,60">Search</A> |
           <A href="top10.html" shape="poly" coords="276,0,373,28,50,50,100,120">Top Ten</A>
         </MAP>
       </BODY>
    </HTML>

In the following example, we create a similar image map, this time using the `AREA` element. Note the use of `alt` text:

    <P><OBJECT data="navbar1.gif" type="image/gif" usemap="#map1">
       <P>This is a navigation bar.
       </OBJECT>

    <MAP name="map1">
     <AREA href="guide.html"
              alt="Access Guide"
              shape="rect"
              coords="0,0,118,28">
     <AREA href="search.html"
              alt="Search"
              shape="rect"
              coords="184,0,276,28">
     <AREA href="shortcut.html"
              alt="Go"
              shape="circle"
              coords="184,200,60">
     <AREA href="top10.html"
              alt="Top Ten"
              shape="poly"
              coords="276,0,373,28,50,50,100,120">
    </MAP>

Here is a similar version using the `IMG` element instead of `OBJECT` (with the same `MAP` declaration):

    <P><IMG src="navbar1.gif" usemap="#map1" alt="navigation bar">

The following example illustrates how image maps may be shared.

Nested `OBJECT` elements are useful for providing fallbacks in case a user agent doesn't support certain formats. For example:

    <P>
    <OBJECT data="navbar.png" type="image/png">
      <OBJECT data="navbar.gif" type="image/gif">
        text describing the image...
      </OBJECT>
    </OBJECT>

If the user agent doesn't support the PNG format, it tries to render the GIF image. If it doesn't support GIF (e.g., it's a speech-based user agent), it defaults to the text description provided as the content of the inner `OBJECT` element. When `OBJECT` elements are nested this way, authors may share image maps among them:

    <P>
    <OBJECT data="navbar.png" type="image/png" usemap="#map1">
      <OBJECT data="navbar.gif" type="image/gif" usemap="#map1">
         <MAP name="map1">
         <P>Navigate the site:
          <A href="guide.html" shape="rect" coords="0,0,118,28">Access Guide</a> |
          <A href="shortcut.html" shape="rect" coords="118,0,184,28">Go</A> |
          <A href="search.html" shape="circle" coords="184,200,60">Search</A> |
          <A href="top10.html" shape="poly" coords="276,0,373,28,50,50,100,120">Top Ten</A>
         </MAP>
      </OBJECT>
    </OBJECT>

The following example illustrates how anchors may be specified to create inactive zones within an image map. The first anchor specifies a small circular region with no associated link. The second anchor specifies a larger circular region with the same center coordinates. Combined, the two form a ring whose center is inactive and whose rim is active. The order of the anchor definitions is important, since the smaller circle must override the larger circle.

    <MAP name="map1">
    <P>
    <A shape="circle" coords="100,200,50">I'm inactive.</A>
    <A href="outer-ring-link.html" shape="circle" coords="100,200,250">I'm active.</A>
    </MAP>

Similarly, the `nohref` attribute for the `AREA` element declares that geometric region has no associated link.

### 13.6.2 Server-side image maps

Server-side image maps may be interesting in cases where the image map is too complicated for a client-side image map.

It is only possible to define a server-side image map for the `IMG` and `INPUT` elements. In the case of `IMG`, the `IMG` must be inside an `A` element and the boolean attribute `ismap` ([CI]) must be set. In the case of `INPUT`, the `INPUT` must be of type "image".

When the user activates the link by clicking on the image, the screen coordinates are sent directly to the server where the document resides. Screen coordinates are expressed as screen pixel values relative to the image. For normative information about the definition of a pixel and how to scale it, please consult [CSS1].

In the following example, the active region defines a server-side link. Thus, a click anywhere on the image will cause the click's coordinates to be sent to the server.

    <P><A href="http://www.acme.com/cgi-bin/competition">
            <IMG src="game.gif" ismap alt="target"></A>

The location clicked is passed to the server as follows. The user agent derives a new URI from the URI specified by the `href` attribute of the `A` element, by appending `?' followed by the x and y coordinates, separated by a comma. The link is then followed using the new URI. For instance, in the given example, if the user clicks at the location x=10, y=27 then the derived URI is "http://www.acme.com/cgi-bin/competition?10,27".

User agents that do not offer the user a means to select specific coordinates (e.g., non-graphical user agents that rely on keyboard input, speech-based user agents, etc.) should send the coordinates "0,0" to the server when the link is activated.

## 13.7 Visual presentation of images, objects, and applets

All `IMG` and `OBJECT` attributes that concern visual alignment and presentation have been deprecated in favor of style sheets.

### 13.7.1 Width and height

Attribute definitions

`width` = length [CN]
  Image and object width override.
`height` = length [CN]
  Image and object override.

When specified, the `width` and `height` attributes tell user agents to override the natural image or object size in favor of these values.

When the object is an image, it is scaled. User agents should do their best to scale an object or image to match the width and height specified by the author. Note that lengths expressed as percentages are based on the horizontal or vertical space currently available, not on the natural size of the image, object, or applet.

The `height` and `width` attributes give user agents an idea of the size of an image or object so that they may reserve space for it and continue rendering the document while waiting for the image data.

### 13.7.2 White space around images and objects

The `vspace` and `hspace` attributes specify the amount of white space to be inserted to the left and right (hspace) and above and below (vspace) an `IMG`, `APPLET`, `OBJECT`. The default value for these attributes is not specified, but is generally a small, non-zero length. Both attributes take values of type length.

### 13.7.3 Borders

An image or object may be surrounded by a border (e.g., when a border is specified by the user or when the image is the content of an `A` element).

Attribute definitions

`border` = pixels
  Deprecated. The `border` attribute specifies the width of this border in pixels. The default value for this attribute depends on the user agent.

### 13.7.4 Alignment

The `align` attribute specifies the position of an `IMG`, `OBJECT`, or `APPLET` with respect to its context.

The following values for `align` concern the object's position with respect to surrounding text:

- `bottom:` means that the bottom of the object should be vertically aligned with the current baseline. This is the default value.
- `middle:` means that the center of the object should be vertically aligned with the current baseline.
- `top:` means that the top of the object should be vertically aligned with the top of the current text line.

Two other values, `left` and `right`, cause the image to float to the current left or right margin. They are discussed in the section on floating objects.

Differing interpretations of align. User agents vary in their interpretation of the `align` attribute. Some only take into account what has occurred on the text line prior to the element, some take into account the text on both sides of the element.

## 13.8 How to specify alternate text

Attribute definitions

`alt` = text [CS]
  For user agents that cannot display images, forms, or applets, this attribute specifies alternate text. The language of the alternate text is specified by the `lang` attribute.

Several non-textual elements (`IMG`, `AREA`, `APPLET`, and `INPUT`) let authors specify alternate text to serve as content when the element cannot be rendered normally. Specifying alternate text assists users without graphic display terminals, users whose browsers don't support forms, visually impaired users, those who use speech synthesizers, those who have configured their graphical user agents not to display images, etc.

The `alt` attribute must be specified for the `IMG` and `AREA` elements. It is optional for the `INPUT` and `APPLET` elements.

While alternate text may be very helpful, it must be handled with care. Authors should observe the following guidelines:

- Do not specify irrelevant alternate text when including images intended to format a page, for instance, `alt="red ball"` would be inappropriate for an image that adds a red ball for decorating a heading or paragraph. In such cases, the alternate text should be the empty string (""). Authors are in any case advised to avoid using images to format pages; style sheets should be used instead.
- Do not specify meaningless alternate text (e.g., "dummy text"). Not only will this frustrate users, it will slow down user agents that must convert text to speech or braille output.

Implementors should consult the section on generating alternate text for information about how to handle cases of omitted alternate text.

Note. For more information about designing accessible HTML documents, please consult [WAIGUIDE].