[<== Previous] | [Up] | [Next ==>]
To the graphical-designer crowd, images are the whole purpose of the Web,
and they can't imagine that the Web ever existed without them. Actually,
when HTML was first developed, it was a text-only medium, and the use
of inline graphics was a later addition. The innovations that made the Web a
novel, useful medium were not the graphical interface of browsers or
Web page layouts, but rather, the creation of a universal addressing
syntax for net-wide resources (the URL system), the
creation of a simple hypertext language allowing documents with embedded links (HTML),
and a simple protocol to transmit these documents (HTTP). All of these things
came about prior to the existence of graphical browsers. Believe it or not, one can actually
create an interesting, useful Web site with few or no graphics -- look at
this one for instance! But most of you will want
to add some pictures along with your text, and that's fine. Just follow
a few pointers to make your site work best for both the graphical and
non-graphical browsers out there.
<IMG SRC="gfx/myhouse.gif" WIDTH=96 HEIGHT=64
ALT="[Picture of my house]">
Some currently-popular formats of graphics, in the Web and elsewhere, are:
- GIF -- The most popular Web graphic format, supported by all graphical
browsers. GIFs are usually best (in terms of smaller file size) for line art and
computer-generated graphics, but are limited to 256 colors. The compression routine used in GIF is LZW, which
Unisys has a patent on, and they raised a big
stink in the net a few years ago by suing various companies that created software using
this format (especially CompuServe, which created
the format in the first place, not realizing the algorithm was patented).
Despite serious legal questions about the enforceability of such software patents, they
managed to bully various people into paying them royalties, but
many others still don't, and for a while Unisys didn't seem to be suing anybody else.
Also, their own statements implied that only software developers are affected, and
you couldn't get sued for using GIFs in a Web site, only for
publishing software that creates or reads the format.
However, they later contradicted themselves and hinted at increasing litigiousness:
see an article in Slashdot.
Now they imply that you could get sued for using GIFs on your Web site that were produced
using an unlicensed graphic program. It's dubious whether this would hold up in court,
or indeed if they could even prove what program you used to make your GIFs anyway.
Fortunately, the patent in question expires on June 20, 2003, so the end to this nuisance is now in sight.
(MIME type: image/gif.)
(Aside: While some people pronounce "GIF" with a hard "G", the original intended
pronunciation has a soft "G", like "Jif". However, where I used to live (Shreveport, LA) there's a local
politician whose first name is Gif, and he pronounces it with a hard "G".)
- JPEG -- Supported by almost all graphical browsers, this format has the best
compression for many photographic images, and is in true-color (millions of colors)
mode. It's a "lossy" compression routine that may blur details in the picture.
Usually the file extension is .jpg to work under DOS and Windows 3.1, though
the full .jpeg extension is sometimes found, as is .jpe, another abbreviated
version. (MIME type: image/jpeg.)
- PNG -- Created by some developers who were ticked off at Unisys for claiming
patent protection on the compression used in the GIF format, it has been touted as
a totally free, and improved-technology, graphic format to replace GIF. Support of this
format in browsers lagged considerably behind the other formats for a long time, and many
server administrators haven't bothered to configure their servers to send the proper
MIME type for .png files so that the browsers that do support it will do the right
thing with them. However, by now, it's reasonably safe to use PNG graphics on the Web.
(MIME type: image/png. Sometimes image/x-png is used,
but this format is officially registered, so the "x" isn't necessary.)
- BMP -- The standard Windows and OS/2 bitmap format, used for wallpapers, etc.
It's not generally used on the Web, but Microsoft Internet Explorer supports it (Netscape 4.x or earlier
doesn't). I don't think there's even an official MIME type for it, but that's OK with MSIE
since it mostly ignores MIME types anyway, in defiance of the standard that says that these
type-definition headers sent by the server should be used to determine what type of data
is being sent. Anyway, it's not a good idea to use BMP files; even if they were
supported by more browsers, they're a wasteful format since they're not compressed, and are
thus much larger than the same graphic as a GIF or JPEG.
- PCX -- Commonly used for clip art files (especially a few years ago; it seems to
be declining in popularity these days), but not used on the Web; I don't think any browsers
support it, and there isn't even a standard MIME type for it.
- TIFF -- Another common clip art file type, but not used on the Web very much.
Some TIFF files use LZW compression, putting them at the same legal risk as GIFs with
regard to the Unisys patent. (MIME type: image/tiff)
TIP: Always use
attributes with images, and they should equal the actual size of the image,
rather than be used to force the browser to resize it.
HEIGHT attributes let the browser lay out the entire page before it succeeds in
loading all of the graphics. Without them, it has to wait until the graphic is loaded before it knows
where to put anything below or to the right of the graphic. Over a modem connection, it could take a
while to load all the graphics, and the user may be faced with a blank screen until then. It's much
more friendly to let the user start reading the page earlier, and it may even let you get away with
putting more, larger, fancier-looking graphics without making the page intolerable!
While many browsers will re-size a graphic if you use
HEIGHT attributes different from the actual size of the graphic,
please resist the urge to use this to make your graphics fit a desired
layout. Why? Here's some reasons:
- Some older browsers may ignore these attributes
and not size the graphic correctly.
- If you use this technique to make
the graphic smaller than it really is, you're wasting the users' time by
making them download an excessively large graphic; you should have resized
it first in your art program before putting it up on the net. (I've actually
seen 1024-pixel-wide, 500 kilobyte graphic files resized by
HEIGHT attributes to be small icons on people's Web pages.
Properly reduced, these images could have been made to be more like 10
kilobytes, saving great amounts of data transfer time and disk space!)
- If you use this to make the graphic larger than it really
is, it will probably look really ugly; the pixels will be stretched out to
fill the larger space, producing an effect greatly inferior to what an
artist could achieve by creating the graphic in the proper size to start
TIP: Don't use an image straight out of
your digital camera! Those images are generally at a much higher resolution level
than is useful for the Web. You should use an image editor program (e.g., Photoshop,
Paint Shop Pro, etc.) to reduce it to a smaller size. The same usually applies to
images from a scanner, unless you used a scan resolution that is "web-sized" to
begin with. [Suggested by Dan Jacobson]
Some Bad Examples
Example 1: Your browser had to load a large,
full-sized graphic then resize it to the "thumbnail" above.
Example 2: A small button was resized to be large,
and boy it looks ugly!
There's one reason why some Web designers sometimes
choose not to use
HEIGHT: in some
browsers (Netscape in particular), if the size of the graphic isn't large enough to fit the
ALT text (see explanation of the
attribute below) then it will be omitted or truncated
when graphics loading is turned off, and the user misses out on some of
the content. If
HEIGHT is omitted,
the missing graphic is sized to fit the
ALT text. In most
cases this isn't a problem since a graphic with lots of text in it is
probably big enough to hold the same text in its
But there may be a few cases of graphics needing alternative text bigger
than the graphic itself (a picture is worth a thousand words, after all),
so that's something for the author to consider. It then becomes a matter
of opinion whether to use or omit the size attributes; I still favor
leaving them in, but a case can be made in the other direction.
ALT text with all of your
images, and put careful thought into making this text "flow well" for
nongraphical browser users.
ALT text is intended to substitute for the graphic for users with text-only browsers
(such as Lynx, or text-readers used by blind people), or with graphics turned off (as some users with
slow connections do), and it's also displayed by some browsers until the graphic loads. So, in
HEIGHT, it helps the user find something useful on the page without
waiting for the graphics to come up. You may think that the
fondest wish of all users is to see your brilliant graphical layouts, but maybe, especially
when returning to a site they've already been to, they're simply trying to get quickly to some part of the site,
and the presence of
ALT text lets them see quickly which button to click on.
NOTE: You may actually have a "text browser" without even knowing it. In many browser
versions (e.g., Netscape and Mozilla), try the "Save As" feature in the "File" menu, picking "Plain Text" as the format
to save. This will save the current page as plain text, which is rendered in much the same
manner as a text browser would -- with images replaced with their ALT text. This can be a
very useful feature if you want to save the text content of a Web document for later use (such
as e-mailing to somebody or importing as plain text into another document you're working on)
without all the graphics and formatting. But it works best when the Web page you're saving
was designed to work well on text browsers, including sensible use of ALT text.
(Microsoft Internet Explorer has a greatly inferior "save-as-text" feature, which
ignores ALT text and just extracts the normal text of the document, poorly formatted.
Mozilla and Netscape 6.0 and up are somewhere in between, using the ALT text but not doing as good a job at formatting
the page in text mode as earlier Netscape browsers.)
ALT text that "flows" well when the graphic is replaced by the text. Some people do silly things
ALT="big red bullet" for graphical "bullets" used before items in a list. If you read the page out
loud using this everywhere a bullet appears, you'll see how ridiculous it is. Instead, use
ALT="----------" for horizontal rules,
ALT="W" for a giant capital letter W at the
beginning of a sentence (if you insist on using a graphic for this sort of thing),
Graphical Glitziness Society" for a logo with an organization name at the top of a Web page (if you just
do something like
ALT="logo" a text-mode user won't even know what organization it is!) Use an empty
ALT="", for graphics that are purely decorations, or empty "spacers", to suppress an
[INLINE]" that a text-only browser like Lynx will show otherwise. For buttons and icons
in rows, you may want to surround the
ALT texts with square brackets so they don't run together.
TIP: Avoid giving your text-mode users "Double Double Vision Vision"
by using redundant ALT text! For instance, if you have a product page with a text header
at the top that says "Solid Mahogany Chicken Coop," followed by a picture of the item, you
probably shouldn't use
ALT="Solid Mahogany Chicken Coop" as the picture's ALT text,
since that would make a text browser show that phrase twice in a row (and make an audio
browser sound like it has an echo). It would be better to use something
ALT="[Picture of product]", indicating the purpose of the image
non-redundantly, in square brackets to set it off from the other text of the page.
Or, if you consider the image just a decoration that text-mode users won't really care
about the existence of, you could use an empty
ALT="". (But don't do this
if the image is an important illustration that users might want to bring up another browser
or external image viewer to see; in such cases, the ALT text can serve a valuable function
in alerting the user to its existence and purpose.)
If a graphic at the top of a page serves as the main title header of the
page, surround it with a
<H1> tag so that non-graphical browsers will
render the ALT text in the style appropriate to such a header; for instance:
<H1 ALIGN=CENTER><IMG SRC="gfx/logo.gif" WIDTH=400 HEIGHT=100
Don't let the above-mentioned "mis-feature" of Netscape (4.x and earlier),
that ALT text doesn't show in graphics too small for it to fit, cause you to choose to omit
ALT text in such cases because "it doesn't fit anyway". Users of many other browsers will see
your "non-fitting" ALT text in its full glory.
Most versions of Netscape prior to 6.0, as well as MSIE, show the
ALT text when you hold your
mouse over a graphic, so even they can see it now. But that shouldn't
lead you to code ALT text specifically for the purpose of
"pop-up toolbar text" (which would imply that
you should make it supplemental to the graphic rather than a replacement
for it); this would produce awkward results when the ALT text is used
in its original intended purpose as a substitute for the graphic
in nongraphical browsers or when graphic loading is turned off. (Mozilla doesn't show ALT text as
"tool tips", though they're under constant pressure in newsgroups, web forums,
and Bugzilla to "cave in" and do
it for "compatibility" with other browsers.)
These are specific instances of a general rule that
you shouldn't code your Web site specifically to the features or
bugs of a particular browser, but rather use sensible markup that
expresses the meaning of your document in a platform-independent way.
If you add or omit things solely because they are or aren't supported on some specific version of some
specific browser, you may be shortchanging users of other browsers
(including the next version of the same browser) from getting the full
content of your site. After you have sound, logical HTML code in place,
you can "tweak" it carefully to work around browser bugs and support
browser-specific enhancements, but get the basic structure in place first.
Yet another thing not to do with image ALT text is to use it to
"spamdex" the search engines by putting huge lists of keywords in every image.
This looks completely idiotic whenever the ALT text is shown in a browser, like
in a text browser, a graphical browser with images turned off, or, in the latest
versions of Netscape and Internet Explorer, as a tool-tip when you hold the mouse over an
image. It greatly increases the size of the page and the length of time it takes to load.
And it may not even work to improve your search indexing; such excessive repetition
may well trigger the "anti-spamdexing" penalties, plus there are some search engines that
ignore ALT text anyway.
Some search engines do look at ALT text when indexing, though, so the presence
of ALT text can be of assistance in regaining the honest degree of indexing your site may lose
by using graphics instead of text for parts of its main content. Just don't abuse this by
trying to artificially stuff keywords where they don't belong.
ALIGN attribute gives you a little bit of control over
positioning of a graphic with respect to adjacent text.
Here I used
to line the top of the image up with the top of the text line. Note that once the text
wordwraps, the next line begins below the image.
Here I used
to line the bottom of the image up with the bottom of the text line.
Here I used
to line the image up with the middle of the text line. Or, at least, it's
supposed to be that way; Netscape doesn't actually do this, so
you may see the text off-center.
Here I used
to line the image up with the middle of the text line for Netscape users.
Other browsers might ignore this attribute, because it is nonstandard.
Netscape chose to implement it to provide true vertical centering rather
than fix their broken implementation of the
attribute. Unfortunately, even this attribute doesn't always produce
correct vertical centering in all Netscape versions.
Here I used
ALIGN=LEFT to place the graphic
to the left with the text filling the space to the right until the
bottom of the graphic is reached.
Here I used
ALIGN=RIGHT to place the graphic
to the right with the text filling the space to the left until the
bottom of the graphic is reached.
If you use
ALIGN=RIGHT, but you have a
piece of text soon afterward that you don't want to have wrap around
the image (in other words, you want to make sure you get clear of the image
and start a new line below it), insert
<BR CLEAR="right"> (depending on which side the image is
<BR CLEAR="all"> to clear all aligned images,
left or right.
When you have a graphic that's also a link, there are two ways you can get
unsightly blue lines (or whatever color links are on that page). One is the
border around the graphic that shows up by default when it's a link. Get
rid of that by adding
BORDER=0 to the
Some purists complain about this because it makes user interfaces inconsistent
by removing the normal cue that something is a link (as well as the color
change that indicates whether the link has already been visited), but in
many cases the border looks really ugly, so it's common to suppress it.
Just try to make the graphic look like a button so that people know they
can click on it.
The other "ugly line" you can get is the small blue line immediately
following a link graphic because you put the closing
tag on a new line following the graphic. Although line breaks in your
HTML document are normally ignored, there are some positions at which they
cause some browsers to insert an extra space, which, if it's in a link,
will be underlined. To get rid of it, avoid putting extra line breaks
within a link. The safest place to put a line break is within the angle
brackets of a tag, so it's not processed as extra "whitespace" in the
document text itself.
The Wrong Way
<IMG SRC="gfx/stuff.gif" WIDTH=120 HEIGHT=200 ALT="[Pretty picture]">
The Right Way
<A HREF="link.html"><IMG SRC="gfx/stuff.gif" WIDTH=120
HEIGHT=200 ALT="[Pretty picture]"></A>
Don't laugh! While it's illogical to link to graphics on your hard disk
on a Web page that's out on the Internet (users out there don't have access
to your personal system!), people do it all the time. Generally it's done
using one of those WYSIWYG editors that let you point-and-click to insert
graphics. Supposedly, such links will be automagically converted to links
to the appropriate server address when you upload the site, but some users
leave out a step somewhere, and the pages end up on the server with
embedded graphics like
When the creator checks out the site, these pages look fine because the
graphics are available to the creator, so this error is hard to catch.
So be sure to look at the site on somebody else's computer... if it's
full of "broken graphic" icons that didn't appear on your system, you've
probably made this goof.
Better yet, dump that silly WYSIWYG editor and edit your Web pages in
a plain-ASCII editor... you're almost certain not to type in something
as silly as a link to your hard disk if you type it in by hand!
If you're thinking of putting an imagemap on your site for purposes
of navigation, first ask: Why? I can give you lots of "Why Not"'s.
Imagemaps are useless to text-mode browsers like Lynx or for users who
have turned graphic loading off. With the old-style server-side imagemaps,
the user can't even see where a link goes to until clicking on it; the
normal status-line cue is absent. The newer client-side imagemaps are
better; you can see the link's URL in the status line, and some new
versions of Lynx can even handle this sort of imagemap (if you use ALT
text for the links). But there may still be a few old browsers out
there that don't support client-side imagemaps, so you'll end up having
to create both kinds of imagemaps in one to handle everybody.
In general, if what you want is a row of buttons going to various parts
of your site, it's better to have separate graphics for each button,
separately linked to the appropriate place and with ALT text in each
image. This provides a navigational tool that works in graphic or text
mode for all browsers. Or you can lower the bandwidth even more by
eschewing graphical buttons altogether and using text links! They work
fine and take much less time to load, and if you play around with
table background colors and <FONT> attributes (or, of course,
stylesheets once they become better-supported), you can even achieve some fancy
There are some things an imagemap is still good for: if you want a clickable
map of the country or your hometown, with different sites for different
geographical regions, an imagemap will work. But be sure to provide an
alternative means of navigation for nongraphical users, such as an
alphabetical list of states or cities below the map.
Why Do My Graphics Look So Sucky on AOL?
AOL sends all Web sites through its own servers before
sending them to the user's browser (part of the AOL software; presently an adapted version
of MSIE, but likely to eventually change to Netscape now that AOL owns them). Rather than
simply pass the data on unchanged, AOL does some stuff to it, including caching (so the version
of a page you see might not always be the latest one, even if you press the "Reload" button
in your browser), and also image compression. This compression (into a proprietary "ART" format)
will sometimes mess up the quality of the image, particularly with JPEGs (already compressed
in a "lossy" manner). There's a configuration setting in the AOL software to disable this
image compression; use it if you want to see sites' graphics at full quality. But there's
no way (that I know of) that you as a Web developer can ensure that your graphics won't be "munged" by AOL.
By the way, if you're an AOL user publishing a Web page in the free space they provide,
don't put your images up in the AOL "ART" format. Such images will be visible to other
AOL users, but nobody else, since non-AOL browsers don't support the format. Use a more
widely supported graphic format like GIF or JPEG.
Make your site better by looking at other sites that show, by example, what
not to do!
NOTE: The inclusion of a site in my "Hall of Shame" links should not
be construed as any sort of personal attack on the site's creator, who may be a really great
person, or even an attack on the linked Web site as a whole, which may be a source of
really great information and/or entertainment. Rather, it is simply to highlight specific
features (intentional or accidental) of the linked sites which cause problems that could
have been avoided by better design. If you find one of your sites is linked here,
don't get offended; improve your site so that I'll have to take down the link! (Most of the stuff
that used to be in this list has been removed, since subsequent site redesigns removed the "features"
I was complaining about.)
- Gould Academy's home page used to have
no text whatsoever, only images and imagemaps with absolutely no ALT text; it's not quite so
bad now, but still has lots of images (including text-as-graphics) with missing ALTs.
- This page in the Canadian
Internet Registration Authority's site has nothing but a huge imagemap
with missing or empty ALT attributes (for the image and the links).
- Apple's online store (which belongs on my Domain
Hall of Fame for using a logical subdomain instead of a Stupid Unnecessary Domain Name) unfortunately isn't
so fame-worthy in its graphic use; it has silly ALT attributes like "Image" for many images, including those with
important navigation buttons.
- Sinead Quinn's site uses empty ALT text for various important
images such as text-as-graphic navigation links, as if they were mere spacers or decorative images.
- The Risks Digest Archives is a site with
very interesting discussions of technological risks, which I read regularly. Unfortunately,
the site maintainer decided to add a little decoration to the all-text content of the
digest issues by putting in a few graphical bullets and horizontal rules, and he neglected
HEIGHT attributes in the horizontal rules. This
means that I'm prevented from scrolling past the table of contents until the graphic loads,
which usually doesn't happen until the whole (fairly large) text of the issue is loaded.
If only they used the right attributes, I could have been reading the issue even before
all of it loaded.
[<== Previous] | [Up] | [Next ==>]
This page was first created 13 Jul 1997, and was last modified 18 Jun 2012.
Copyright © 1997-2012 by Daniel R. Tobias. All rights reserved.