The positioning of the image is affected by the attributes of the IMG element.
attribute name | possible values | meaning | notes |
---|---|---|---|
SRC | URL | address of the image | obligatory; see notes on graphics formats |
ALT | string | text description of the image | strongly recommendable, and required in HTML 4.0. |
ALIGN | TOP, MIDDLE, BOTTOM, LEFT, RIGHT | positioning of the image relative to the current textline | default is BOTTOM |
HEIGHT | integer | suggested height, in pixels | suggestion only |
WIDTH | integer | suggested width, in pixels | suggestion only |
BORDER | integer | suggested line border width, in pixels | relevant when the IMG element appears as an anchor text; BORDER=0 suppresses the border |
HSPACE | integer | suggested horizontal gutter (width of white space to the immediate left and right of the image), in pixels | default value is a small non-zero number |
VSPACE | integer | suggested vertical gutter (height of white space above and below the image), in pixels | default value is a small non-zero number |
USEMAP | URL | fragment identifier for a client-side image map | maps are defined with the MAP element; names of maps are case sensitive |
ISMAP | ISMAP | indicates that the image is a server-side image map | when the user clicks on the image, this attribute causes the cursor location to be passed to the server. |
The presentational attributes ALIGN, BORDER, HSPACE, and VSPACE are deprecated in HTML 4.0.
Attributes HEIGHT, WIDTH, HSPACE, VSPACE, and USEMAP were not in HTML 2.0! And in HTML 2.0 the allowed values for ALIGN were TOP, MIDDLE, BOTTOM only.
The WIDTH and HEIGHT attributes, when used together, allow browsers to reserve screen space for the image before the image data has arrived over the network. This may imply faster formatting and allow the user to start reading while data transfer is still in progress. These attributes were not designed for automatic resizing of images by browsers. Although some browsers are able to scale the image according to WIDTH and HEIGHT attributes, donīt rely on it. Even if a browser does the scaling, it might do it very poorly, distorting the image, and the scaling might slow down page repainting a lot. Thus the attributes, if used, should specify the true size of the image. (Use a suitable program, such as xv on many Unix systems, for finding out the size in pixels and for scaling the image if needed.) On the other hand, many people omit these attributes; one reason to that is that with image loading turned off, a graphical browser typically still reserves space according to these attributes, if present, and this may imply that the ALT text does not fit there. Thus it seems advisable not to include these attributes if the image is small and the ALT text is important.
The different values of ALIGN have the following meanings:
Note that some browsers (e.g. Internet Explorer 2.0 and 3.0) introduce spurious spacing with multiple left or right aligned images. As a result authors can't depend on this being the same for browsers from different vendors. See BR for ways to control text flow.
When an IMG element contains the ISMAP attribute, the element must be contained in an A element with an HREF attribute. Example:
<a href="/cgibin/navbar.map"><img src=navbar.gif ismap border=0></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 by
appending
a question mark (?),
the x coordinate, a comma (,), and and the y coordinate of the location,
with coordinates expressed in
in pixels. The link is then followed using the new URL. For instance, if
the user clicked at at the location x=10, y=27 then the derived URL will
be: "/cgibin/navbar.map?10,27"
. - It is generally a good idea to
suppress the
border
(using the attribute BORDER=0)
and
explicitly state
that the image
is clickable.
<IMG SRC="Yucca.jpg" ALT="[Picture of Yucca]" WIDTH=115 HEIGHT=178> <P> <IMG SRC="Yucca.jpg" ALT="[Picture of Yucca]" WIDTH=115 HEIGHT=178 ALIGN=RIGHT> This is a simple example of embedding images. This paragraph should be displayed, in a graphical browser, with an image at the right, and before this paragraph the same image should appear separately, with default alignment. </P>
Using IMG with ISMAP, to create a clickable map (the example does not work any more):
<A HREF="http://www.hut.fi/cgi-bin/imagemap/Pictures/English/english.map"> <IMG HEIGHT="400" WIDTH="400" SRC="http://www.hut.fi/Pictures/English/english.gif" ALT="Helsinki University of Technology" ISMAP> </A>
There is no HTML feature specifically intended for a caption for an image. One reasonable way of including a caption (when the image appears on its own and not alongside with the text) is the following:
<P> <IMG SRC="sae.gif" ALT="[Siamese algae eater]"> <BR> Siamese algae eater. <SMALL>Drawing by <A HREF="http://www.hut.fi/u/lsarakon/">Liisa Sarakontu</A>.</SMALL> </P>
If you want a picture appear at the left (or right) of a text paragraph, you should put the IMG element (with ALIGN=LEFT or ALIGN=RIGHT attribute) at the beginning of the paragraph (P element). Otherwise the result may look messy. Moreover, it is good practise to have a BR element with the CLEAR attribute at the end of such a paragraph, to avoid confusing effects. In general, putting an image alongside text is a potential source of problems; for example, a user with a narrow window might not see the text at all.
The ALT attribute is not formally required in HTML 3.2, but it is wise to include it for every image. In some cases it is very obvious what you should put there. For example, if the image presents some text in a specific visual form, it is natural to have that text as the value of an ALT attribute. If the image is purely decorative, you should use ALT="". But there are cases where it can be somewhat difficult to create a suitable ALT attribute.
The semantics and intended use of the ALT attribute are somewhat vague. It might be viewed as a recommended way of providing a textual presentation of the contents of an image, to be used as a replacement for the image in text-only browsers, speech-based user agents etc. However, much more typically it contains a verbal explanation of the image, such as a title or perhaps just a name for the image. This seems suitable in the common situation of using a graphical browser with automatic image loading disabled: the user decides on the basis of the verbal explanation whether to load this particular image. (Graphic browsers vary in their behavior in such situation: treatment of ALT attributes in the situation where the user has turned off some browsers display the ALT value, others may display a small generic image which says very little.) And it is often difficult to say how the ALT text could be a good replacement for the image, since the syntax restricts the value to be just a string with no HTML markup. - Alan Flavell has written an extensive document Use of ALT texts in IMGs. See also my Simple guidelines on using ALT texts in IMG elements.
There are two ways of implementing clickable image maps in HTML documents:
imagemap
or htimage
; consult the documentation of the
server).
<A HREF="/cgi-bin/htimage/your.map"> <IMG SRC="image/your.gif" ... ISMAP USEMAP="#yourmap"></A>That way new browsers will use the client side image map, whereas old browsers will ignore the USEMAP attribute and pass the request to the server.
For more information about image maps, see e.g.
Image maps can be very useful in association with geographical maps.
(See e.g. the "Virtual Tourist" map at
http://www.vtourist.com/travel/
.)
They might conceivably be used in other contexts as well, for instance
to allow the user select an item in a display of purchasable objects
or a detail in a plan of a house or
to request information about a part of a device described
by a drawing.
In general, an imagemap can be
very useful for things which are inherently visual
in two or more dimensions.
However, in actual practice
most use of image maps is abuse.
Example 2
above
is a typical case: a natural, simple text menu would be easier to use
and more efficient, and it would work fine on text-only browsers, too.
(See section Using
tables to represent menus for various implementations of menus.)