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 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:
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 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.
<!-- 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) --
nameCDATA #IMPLIED -- name of image for scripting --
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 --
>
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. Since an
IMG element may be within the content of an A element,
the user agent's mechanism in the user interface for accessing the "longdesc"
resource of the former must be different than the mechanism for accessing the
href resource of the latter.
This attribute names the element so that it may be referred to from style
sheets or scripts. Note. This attribute has been included for
backwards compatibility. Applications should use the id
attribute to identify elements.
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".
<!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 --
archiveCDATA #IMPLIED -- space-separated list of URIs --
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 --
nameCDATA #IMPLIED -- submit as part of form --
tabindexNUMBER #IMPLIED -- position in tabbing order --
>
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.
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.
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.
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.
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. If the value of this attribute differs from the HTTP
Content-Type returned by the server when the object is retrieved, the HTTP
Content-Type takes precedence.
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.
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.
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).
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.
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.
A user agent must interpret an OBJECT element according to the
following precedence rules:
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).
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.
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:
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>
<!ELEMENT PARAM - O EMPTY -- named property value -->
<!ATTLIST PARAM
idID #IMPLIED -- document-wide unique id --
nameCDATA #REQUIRED -- property name --
valueCDATA #IMPLIED -- property value --
valuetype (DATA|REF|OBJECT) DATA -- How to interpret value --
type%ContentType; #IMPLIED -- content type for value
when valuetype=ref --
>
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.
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.
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.
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 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.
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.
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.
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.
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>
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 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.
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. Note.
While the restriction on subdirectories is a departure from common practice and
the HTML 3.2 specification, the HTML Working Group has chosen to leave the
restriction in this version of the specification for security
reasons.
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.
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.
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.
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.
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 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>
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.
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.
<!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 --
tabindexNUMBER #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 --
>
This attribute specifies the position and 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. The first x and y
coordinate pair and the last should be the same to close the polygon. When
these coordinate values are not the same, user agents should infer an
additional coordinate pair to close the polygon.
Coordinates are relative to the top, left corner of the object. All values
are lengths. All values are separated
by commas.
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.
The
MAP element specifies a client-side image map (or other navigation
mechanism) that may be associated with another elements (IMG,
OBJECT, or INPUT). An image map is associated with
an element via the element's usemap attribute. The MAP
element may be used without an associated image for general navigation
mechanisms.
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.
The MAP element content model allows authors to
combine the following:
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 user agents do not generally render AREA
elements. Therefore, authors must provide alternate text for each AREA
with the
alt attribute (see below for information on how to specify alternate text).
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 the user agent should render block-level content of
a
MAP element. Authors should use this method to create more
accessible documents.
When a
MAP element contains mixed content (both AREA
elements and block-level content), user agents must ignore the AREA
elements.
Authors should specify an image maps's geometry completely with AREA
elements, or completely with A elements, or completely with both if content is
mixed. Authors may wish to mix content so that older user agents will handle
map geometries specified by AREA elements and new user agents will take
advantage of richer block content.
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.
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:
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:
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.
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.
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.
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.
Deprecated. This
attribute specifies the amount of white space to be inserted to the left and
right of an
IMG, APPLET, or OBJECT. The default value is not
specified, but is generally a small, non-zero length.
Deprecated. This
attribute specifies the amount of white space to be inserted above and below an
IMG, APPLET, or OBJECT. The default value is not
specified, but is generally a small, non-zero length.
Deprecated. This
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.
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 accessibility for information about
how to handle cases of omitted alternate text.
