Contents
HTML's multimedia features allow authors to include images, applets (programs that run on the user's machine), video clips, and other HTML documents in their pages.
Previous versions of HTML allowed authors to include images (via IMG) and applets (via APPLET). These elements have several limitations:
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, but other terms for these things are: components, 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 continue to use the IMG element as well.
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.
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.
<!-- To avoid problems with text-only 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 %URL; #REQUIRED -- URL of image to embed --
alt CDATA #REQUIRED -- short description --
longdesc %URL; #IMPLIED -- link to long description --
align %IAlign; #IMPLIED -- vertical or horizontal alignment --
height %Pixels; #IMPLIED -- suggested height in pixels --
width %Pixels; #IMPLIED -- suggested width in pixels --
border %Pixels; #IMPLIED -- suggested link border width --
hspace %Pixels; #IMPLIED -- suggested horizontal gutter --
vspace %Pixels; #IMPLIED -- suggested vertical gutter --
usemap %URL; #IMPLIED -- use client-side image map --
ismap (ismap) #IMPLIED -- use server-side image map --
>
Start tag: required, End tag: forbidden
Attribute definitions
Attributes defined elsewhere
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 replaced inline by the image designated by the src attribute.
In an earlier example, we defined a link to a family photo. Here, we insert the photo directly into the current document:
<BODY>
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 also be achieved with the OBJECT element as follows:
<BODY>
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 next when they cannot support images, they cannot support a certain image type or when they are configured not to display images.
Please consult the section on the visual presentation of objects, images, and applets for information about image size, alignment, and borders.
<!ELEMENT OBJECT - - (PARAM | %inline; | %blocklevel;)* -- generic embedded object --> <!ATTLIST OBJECT %attrs; -- %coreattrs, %i18n, %events -- declare (declare) #IMPLIED -- declare but don't instantiate flag -- classid %URL; #IMPLIED -- identifies an implementation -- codebase %URL; #IMPLIED -- some systems need an additional URL -- data %URL; #IMPLIED -- reference to object's data -- type %ContentType; #IMPLIED -- Internet content type for data -- codetype %ContentType; #IMPLIED -- Internet content type for code -- archive %URL; #IMPLIED -- space separated archive list -- standby CDATA #IMPLIED -- message to show while loading -- align %IAlign; #IMPLIED -- vertical or horizontal alignment -- height %Length; #IMPLIED -- suggested height -- width %Length; #IMPLIED -- suggested width -- border %Length; #IMPLIED -- suggested link border width -- hspace %Length; #IMPLIED -- suggested horizontal gutter -- vspace %Length; #IMPLIED -- suggested vertical gutter -- usemap %URL; #IMPLIED -- reference to image map -- shapes (shapes) #IMPLIED -- object has shaped hypertext links -- name CDATA #IMPLIED -- submit as part of form -- tabindex NUMBER #IMPLIED -- position in tabbing order -- >
Start tag: required, End tag: required
Attribute definitions
Attributes defined elsewhere
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 objects should be rendered externally or by some program, specified by the author, that renders the object 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 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.
A user agent must interpret an OBJECT element according to the following precedence rules:
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>
Authors should complete this declaration by including alternate text as the contents of OBJECT in case the user agent cannot render the clock.
<OBJECT classid="http://www.miamachina.it/analogclock.py"> An animated clock. </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).
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.
<!-- 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">
<!-- 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.
Please consult the section on the visual presentation of objects, images, and applets for information about object size, alignment, and borders.
<!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 CDATA #IMPLIED -- Internet media type -- >
Start tag: required, End tag: forbidden
Attribute definitions
Attributes defined elsewhere
The PARAM element specifies a set of values that may be required by an object at run-time. Any number of of PARAM elements may appear at the beginning of an OBJECT declaration, in any order. The syntax of names and values is assumed to be understood by the object's implementation. Names and values are passed to the object on its standard input. This specification does not specify how user agents should interpret parameter names that appear twice.
To illustrate the use of PARAM, we returning to the clock example. 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.
<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>
Since the default valuetype for a PARAM element is "data", we could replace the above declarations with either:
<PARAM name="height" value="40"> <PARAM name="width" value="40">
or:
<PARAM name="height" value="40" data> <PARAM name="width" value="40" data>
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 URL designating the resource.
<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.
The location of an object's implementation is given by a URL. As we discussed in the section on URLs, the first segment of an absolute URL specifies the protocol used to transfer the data designated by the URL. For HTML documents, this protocol is generally "http". Some applets might employ other protocols. For instance, when specifying a Java applet, you may use URLs that begin with "java" and for ActiveX applets, you may use "clsid".
In the following example, we insert a Java applet into an HTML document.
<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/octet-stream"
classid="java:program.start">
</OBJECT>
Some rendering schemes require additional information to identify their implementation and must be told where to find that information. You may give path information to the object's implementation via the codebase attribute.
<OBJECT codetype="application/octet-stream"
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 URL that begins with the protocol information "clsid". The data attribute locates the data to render (another clock).
<OBJECT classid="clsid:663C8FEF-1EF9-11CF-A3DB-080036F12502"
data="http://www.acme.com/ole/clock.stm">
This application is not supported.
</OBJECT>
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, you 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 the OBJECT is referenced thereafter.
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.
<OBJECT declare
id="earth_declaration"
data="TheEarth.mpeg"
type="application/mpeg">
The <STRONG>Earth</STRONG> as seen from space.
</OBJECT>
...later in the document...
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).
<OBJECT declare
id="tribune"
type="application/x-webfont"
data="tribune.gif">
</OBJECT>
...view the poem in KublaKhan.txt here...
<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.
<!ELEMENT APPLET - - (PARAM | %inline;)* -- Java applet --> <!ATTLIST APPLET %coreattrs; -- id, class, style, title -- codebase %URL; #IMPLIED -- optional base URL for applet -- archive CDATA #IMPLIED -- comma separated archive list -- code CDATA #IMPLIED -- applet class file -- object CDATA #IMPLIED -- serialized applet file -- alt CDATA #IMPLIED -- short description -- name CDATA #IMPLIED -- allows applets to find each other -- width %Pixels; #REQUIRED -- suggested width in pixels -- height %Pixels; #REQUIRED -- suggested height in pixels -- align %IAlign; #IMPLIED -- vertical or horizontal alignment -- hspace %Pixels; #IMPLIED -- suggested horizontal gutter -- vspace %Pixels; #IMPLIED -- suggested vertical gutter -- >
Start tag: required, End tag: required
Attribute definitions
Attributes defined elsewhere
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. The content must be ignored otherwise.
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:
<OBJECT codetype="application/octet-stream"
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.
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/octet-stream"
classid="AudioItem"
width="15" height="15">
<PARAM name="snd" value="Hello.au|Welcome.au">
Java applet that plays a welcoming sound.
</OBJECT>
An embedded document is entirely independent of the document in which it is embedded. For instance, relative URLs within the embedded document resolve according to the base URL of the embedded document, not that of the main document. Also, an embedded document does not inherit style information from 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 includes 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 included. </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.
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 image maps are preferred over server-side image maps.
HTML 4.0 has two mechanisms for specifying client-side image maps:
For an OBJECT image map, the two methods are mutually exclusive. The presence of either the usemap attribute or the shapes 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.
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.
When MAP and AREA are used, authors are required to provide alternate text for each active region by way of the alt attribute (see below for information on how to specify alternate text). User agents may use this alternate text to create substitute textual links. These links may be activated in a variety of ways (keyboard, voice activation, etc.).
In the case of an OBJECT with the shapes attribute set, authors are required to specify links within the content of the OBJECT itself. Each link defines both the geometry of an active region and the destination program, document, or other resource. When the OBJECT element can be displayed, its content is ignored except for the definitions of the regions. When the OBJECT cannot be displayed, its contents are rendered normally, including the links. Thus, authors are not required to specify alternate text via an alt attribute. This technique also allows richer alternate content that what may be achieved with AREA and its alt attribute.
All elements that may specify a client-side image map that is external to the element must identify by name the MAP element that defines the image map. The usemap attribute links an element to its image map.
Attribute definitions
Here are the DTD fragments for MAP and AREA.
<!ELEMENT MAP - - (AREA)+ -- client-side image map --> <!ATTLIST MAP %attrs; -- %coreattrs, %i18n, %events -- name CDATA #IMPLIED >
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 values -- href %URL; #IMPLIED -- this region acts as hypertext link -- target CDATA #IMPLIED -- where to render linked resource -- nohref (nohref) #IMPLIED -- this region has no action -- alt CDATA #REQUIRED -- short description -- tabindex NUMBER #IMPLIED -- position in tabbing order -- accesskey CDATA #IMPLIED -- accessibility key character -- >
Start tag: required, End tag: forbidden
Attribute definitions
Coordinates are relative to the top, left corner of the object. All values are lengths (they may be pixel values or percentages of the image size).
Attributes defined elsewhere
In the following example, we create a client-side image map for the IMG element with MAP and AREA. We associate the image and the image map by (1) naming the image map with the name attribute of the MAP element and (2) designating that map by setting the usemap attribute on the IMG element.
<IMG src="navbar1.gif" usemap="#map1"></IMG>
<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="circ"
coords="184,200,60">
<AREA href="top10.html"
alt="Top Ten"
shape="poly"
coords="276,0,373,28,50,50,276,0">
</MAP>
If two or more defined regions overlap, the region defined first takes precedence (i.e., responds to user input).
Note: MAP is not backwards compatible with HTML 2.0 user agents.
Attribute definitions
The second way to specify a client-side image map for an OBJECT element is for the author to set the shapes attribute and then to define the image map within the element's content. Each region of the image map is specified by a link (the A element) that has an associated geometric shape (via the shape attribute). The presence of the shapes attribute implies that user agents must parse the contents of the element to look for anchors.
In the following example, we create a client-side image map for the OBJECT element by associating URLs with regions specified by a series of A elements.
<OBJECT data="navbar.gif" shapes> <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="circ" coords="184,200,60">Search</A> | <A href="top10.html" shape="poly" coords="276,0,373,28,50,50,276,0">Top Ten</A> </OBJECT>
It is only possible to define a server-side image map for the IMG and INPUT elements (using MAP and AREA).
In the case of IMG, the IMG must be enclosed by an A element.
In the case of INPUT, the INPUT must be of type "image".
In both cases, the boolean attribute ismap on the element must be set.
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.
<A href="http://www.acme.com/cgi-bin/competition">
<IMG src="game.gif" ismap></A>
The location clicked is passed to the server as follows. The user agent derives a new URL from the URL 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 URL. For instance, in the given example, if the user clicks at at the location x=10, y=27 then the derived URL is "http://www.acme.com/cgi-bin/competition?10,27".
When specified, the height and width attributes for the IMG, APPLET, and OBJECT elements tell user agents to override the natural image size and scale the image to this width and height.
Both attributes take values of type length. User agents should do their best to scale an object or image to match the width and height specified by the author.
At the same time, 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.
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.
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).
The border attribute specifies the width of this border in pixels. The default value for this attribute depends on the user agent.
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:
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.
Attribute definitions
Several non-textual elements (IMG, AREA, APPLET, and INPUT) require authors to 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:
Implementors should consult the section on generating alternate text for information about how to handle cases of omitted alternate text.