Images

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.

Syntax of IMG tag:
<IMG SRC="gfx/myhouse.gif" WIDTH=96 HEIGHT=64
ALT="[Picture of my house]">

Graphic Formats

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)

WIDTH and HEIGHT

TIP: Always use WIDTH and HEIGHT attributes with images, and they should equal the actual size of the image, rather than be used to force the browser to resize it.

The WIDTH and 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 WIDTH and 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:

1. Some older browsers may ignore these attributes and not size the graphic correctly.
2. 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 WIDTH and 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!)
3. 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 with.

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!

But Maybe You Shouldn't Use WIDTH and HEIGHT?

There's one reason why some Web designers sometimes choose not to use WIDTH and 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 ALT 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 WIDTH and 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 ALT form. 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

TIP: Use 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 conjunction with WIDTH and 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.)

Pick ALT text that "flows" well when the graphic is replaced by the text. Some people do silly things like 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 bullets, 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), ALT="The 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, like ALT="", for graphics that are purely decorations, or empty "spacers", to suppress an embedded "[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 like 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 ALT="MegaCorp, Inc."></H1>
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.

The ALIGN Attribute

The ALIGN attribute gives you a little bit of control over positioning of a graphic with respect to adjacent text.
Here I used ALIGN=TOP 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 ALIGN=BOTTOM to line the bottom of the image up with the bottom of the text line.
Here I used ALIGN=MIDDLE 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 ALIGN=ABSMIDDLE 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 ALIGN=MIDDLE 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=LEFT or 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="left"> or <BR CLEAR="right"> (depending on which side the image is aligned), or <BR CLEAR="all"> to clear all aligned images, left or right.

Getting Rid Of Annoying Blue Lines

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 IMG tag. 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 </A> 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

<A HREF="link.html">
<IMG SRC="gfx/stuff.gif" WIDTH=120 HEIGHT=200 ALT="[Pretty picture]">
</A>

The Right Way

<A HREF="link.html"><IMG SRC="gfx/stuff.gif" WIDTH=120
HEIGHT=200 ALT="[Pretty picture]"></A>

Don't Link To Graphics on your Local Hard Disk!

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 <IMG SRC="c:\www\graphics\mypic.gif">. 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!

Imagemaps

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 visual effects.
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.

Hall of Shame

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 to use WIDTH and 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.