 |
Chapter 5 |  |
|
Chapter 5 | |
One of the most compelling features of HTML is its ability to include images with your document text, either as an intrinsic component of the document (inline images), as separate documents specially selected for download via hyperlinks, or, with Netscape and Internet Explorer, as background for your document. When judiciously added to the body content, images--static icons, pictures, illustrations, drawings, and so on--can make your documents more attractive, inviting, and professional looking, as well as informative and easier to browse. You may also specially enable an image so that it becomes a visual map of hyperlinks. When used to excess, however, images make your document cluttered, confusing, and inaccessible, as well as unnecessarily lengthen the time it takes for users to download and view your pages.
The HTML standard does not prescribe an official format for images. However, the popular browsers specifically accommodate only certain image formats; GIF and JPEG, in particular. Most other multimedia formats require special accessory applications that each browser owner must obtain, install, and successfully operate to view the special files. So it's not too surprising that GIF and JPEG are the de facto image standards on the Web.
Both image formats were already in widespread use before the Web came into being, so there's lots of supporting software out there to help you prepare your graphics for either format. However, each has its own advantages and drawbacks, including features that some browsers exploit for special display effects.
The Graphics Interchange Format (GIF) was first developed for image transfer among users of the CompuServe online service. The format serves two purposes: its encoding is cross-platform, so that with appropriate GIF decoding software, graphics created and converted to GIF on a Macintosh, for example, can be loaded into a Windows-based PC, decoded, and viewed without a lot of fuss. The second main feature is that the GIF format uses special compression technology that can significantly reduce the size of the image file for faster transfer over a network. GIF compression is ``lossless,'' too; none of an image's original data is altered or deleted, so the uncompressed and decoded image exactly matches its original.
Even though GIF image files invariably have the .gif (or .GIF) filename suffix, there actually are two GIF versions: the original GIF87 and an expanded GIF89a, which supports several new features including transparent backgrounds popular with HTML authors (see 5.2.1.2, below). The popular browsers support both GIF versions, which use the same encoding scheme that maps 8-bit pixel values to a color table, for a maximum of 256 colors per image. Most GIF images have even fewer colors and there are special tools to simplify the colors in more elaborate graphics. By simplifying the GIF images, you create a smaller color map and enhance pixel redundancy for better file compression and consequent faster downloading.
However, because of the limited number of colors, a GIF-encoded image is not always appropriate, particularly for photorealistic pictures (see JPEG discussion below). Rather, GIFs make excellent icons, reduced color images, and drawings.
Because most graphical browsers explicitly support the GIF format, it is currently the most widely accepted image-encoding format on the Web. It is acceptable for both inline images and externally linked ones. When in doubt as to which image format to use, choose GIF. It will work in almost any situation.
GIF images can be made to perform two special tricks: interlacing and transparency. With interlacing, a GIF image seemingly materializes on the display, rather than progressively flow onto it from top to bottom. Normally, a GIF encoded image is a sequence of pixel data, in order row-by-row, from top to bottom of the image. While the common GIF image renders onscreen like pulling down a window shade, interlaced GIFs open like a venetian blind. That's because interlacing sequences every fourth row of the image. That way, users get to see a full image--top to bottom, albeit fuzzy--in a quarter of the time it takes to download and display the remainder of the image. The resulting quarter-done image usually is clear enough so that users with slow network connections can evaluate whether or not to take the time to download the remainder of the image file.
Not all graphical browsers, although able to display an interlaced GIF, are actually able to display the materializing effects of interlacing. With those that do, users still can defeat the effect by choosing to delay image display until after download and decoding. NCSA Mosaic, on the other hand, always downloads and decodes images before display, so it doesn't support the effect at all.
The other popular effect available with GIF images--GIF89a formatted images actually--is the ability to make a portion of them transparent so that what's underneath--usually the browser window's background--shows through. The transparent GIF image has one color in its color map designated as the background color. The browser simply ignores any pixel in the image that uses that background color, thereby letting the display window's background show through. By carefully cropping its dimensions and by using a solid, contiguous background color, a transparent image can be made to seamlessly meld into a page's surrounding content or float above it.
Transparent GIF images are great for any graphic you want to meld into the document and not stand out as a rectangular block. Transparent GIF logos are very popular, as are transparent icons and dingbats--any graphic that should appear to have an arbitrary, natural shape. You may also insert a transparent image inline with conventional text to act as a special character glyph within conventional text.
The downside to transparency is that the GIF image will look lousy if you don't remove its border when included in a hyperlink anchor (<a> tag), or is otherwise specially framed. And, too, content flow happens around the image's rectangular dimensions, not adjacent to its apparent shape. That can lead to unnecessarily isolated images or odd-looking sections in your HTML pages.
Either and both GIF tricks--interlacing and transparency--don't just happen; you need special software to prepare the GIF file. Many picture tools now save your creations or acquired images in GIF format, although few are able to make interlaced files and fewer let you designate and enable transparency. Fortunately, there are a slew of shareware and freeware programs specialized for either task. Look into your favorite Internet software archives for GIF graphics and conversion tools and also see Chapter 12, Tips, Tricks, and Hacks, for details on creating transparent images.
The Joint Photographic Experts Group is a standards body that developed what is now known as the JPEG image-encoding format. Like GIFs, JPEG images are platform independent and specially compressed for high-speed transfer via digital communication technologies. Unlike GIF, JPEG supports tens of thousands of colors for more detailed, photorealistic digital images. And JPEG uses special algorithms that yield much higher data-compression ratios. It is not uncommon, for example, for a 200-kilobyte GIF image (which uses lossless compression) to be reduced to a 30-kilobyte JPEG image. To achieve that amazing compression, JPEG does lose some image data. However, you can adjust the degree of ``lossiness'' with special JPEG tools, so that although the uncompressed image may not exactly match the original, it will be close enough that most people cannot tell the difference.
The JPEG format is nearly universally understood by today's graphical browsers. Some, most notably Netscape, have a built-in JPEG decoder. Others, like Mosaic, invoke an external viewing tool (helper application) for decoding and displaying JPEG files, which invariably are stored with a .jpg (or .JPG) filename suffix.
The X BitMap image format is an ASCII representation of a monochrome image. It is designed to capture small, black-and-white icons in a form that can be directly included in C and C++ programs. XBM format offers no compression features or support for color images.
XBM format images are typically supported by browsers that run under the X Window System, usually running on a UNIX platform. XBM format is useful for capturing small icons that might be used as bullets or dingbats within a document. It makes little sense to use XBM for any other type of image; the resulting XBM file would be far larger than the equivalent GIF version of the same image.
Most pictures are worth a thousand words. But don't forget that no one pays attention to a blabbermouth. First and foremost, think of your HTML document images as visual tools, not gratuitous trappings. They should support your text content and help readers navigate your documents. Use images to clarify, illustrate, or exemplify the contents. Content supporting photographs, charts, graphs, maps, and drawings are all natural candidates for appropriate HTML images. Product photographs are essential components in online catalogs and shopping guides, for example. And link-enabled icons and dingbats can be effective visual guides to internal and external resources. If an image doesn't do any of these valuable services for your document, throw it out, already!
One of the most important considerations when adding images to a document is the additional delay they add to the retrieval time for a document over the network, particularly for modem connections. While a simple text document might run, at most, 10 or 15 thousand bytes, images can easily extend to hundreds of thousands of bytes each. And the total retrieval time for a document is not only equal to the sum of all its component parts, but also to compounded networking overhead delays since each image requires a separate connection and download request between the client browser and the Web server. Depending on the speed of the connection (bandwidth, usually expressed as bits or bytes per second) as well as network congestion that can delay connections, a single document containing one 100-kilobyte image may take anywhere from around 30 seconds through a 28.8 kilobit-per-second modem connection in the wee hours of the morning when most everyone else is asleep, to well over ten minutes with a 9600 bit-per-second modem at noontime. You get the picture?
Text hasn't gone out of style. For some users, it is the only portion of your document they can access. We argue that, in most circumstances, your documents should be usable by readers who cannot view images or have disabled their automatic download in their browser to improve their low-speed connection. While the urge to add images to all of your documents may be strong, there are times when pure text documents make more sense.
Documents being converted to the Web from other formats rarely have embedded images. Reference materials and other serious content often is completely usable in a text-only form.
You should create text-only documents when access speed is critical and potentially slow. If you know that many users will have only low-speed connections to your pages, you should accommodate them by avoiding the use of images within your documents. Better yet, provide a home (leading) page that lets readers decide between duplicate collections of your work: one containing the images, and another stripped of them. (The popular graphics browsers include special picture icons as place holders for yet-to-be downloaded images, which can trash and muddle your document's layout into an unreadable mess.)
Text is most appropriate--supporting images only, without frills or nonessential graphics--if your documents are to be readily searchable by any of the many Web indexing services. Images are almost always ignored by these search engines. If the major content of your pages is provided with images, very little information about your documents will find its way into the online Web directories.
There are several ways to ameliorate the overhead and delays inherent with images besides being very choosy about which to include in your documents.
A full-screen, 24-bit color graphic, even when reduced in size by digital compression with one of the standard formats like JPEG or GIF, is still going to be a network bandwidth hog. Acquire and use the various image management software to optimize image dimensions and number of colors into the fewest number of pixels. Simplify your drawings. Stay away from panoramic photographs. Avoid large empty backgrounds in your images, as well as gratuitous borders and other space-consuming elements. Also avoid dithering (blending two colors among adjacent pixels to achieve a third color); the technique can significantly reduce the compressibility of your images. Strive for large areas of uniform colors, which compress readily in both GIF and JPEG format.
This is particularly true for icons. The popular browsers cache incoming document components in local storage for the very purpose of quick, network connection-less retrieval of data.
This is a general rule that includes images. Many small document segments, organized through hyperlinks (of course!) and effective tables of contents tend to be better accepted by users than a few large documents. In general, people would rather ``flip'' several pages than dawdle waiting for a large one to download. (It's related to the TV channel-surfing syndrome.) One accepted rule of thumb is to keep your documents under 50 kilobytes each, so even the slowest connections won't overly frustrate your readers.
Provide a special link, perhaps one that includes a thumbnail of the graphic, thereby letting readers decide if and when they want to spend the time downloading the full image. And since the downloaded image isn't mixed with other document components like inline images, it's much easier for the reader to identify and save the image on their system's local storage for later study. (For details on non-inline image downloads, see 5.7).
Finally, another way to improve performance is by including the image's rectangular height and width information in its tag. By supplying those dimensions, you eliminate the extra steps the extended browsers must take to download, examine, and calculate an image's space in the document. There is a downside to this approach, however, that we explore in 5.2.6.11.
You may choose to use only GIF or JPEG images in your HTML documents if your sources for images or your software toolset prefers one over the other format. Both are nearly universally supported by today's browsers, so there shouldn't be any user-viewing problems.
Nevertheless, we recommend that you acquire the facilities to create and convert to both formats, to take advantage of their unique capabilities. For instance, use GIF's transparency feature for icons and dingbats. Alternatively, use JPEG for large and colorful images for faster downloading.
The <img> tag lets you reference and insert a graphic image into the current text flow of your HTML document. There is no implied line or paragraph break before or after the <img> tag, so images can be truly ``inline'' with text and other content.
The format of the image itself is not defined by the HTML standard, although the popular graphical browsers specially support GIF and JPEG images. The HTML standard doesn't specify or restrict the size or dimensions of the image, either. Images may have any number of colors, but how those colors are rendered is highly browser dependent.
Image presentation in general is very browser specific. Images may be ignored by nongraphical browsers. Browsers operating in a constrained environment may modify the image size or complexity. And users, particularly those with slow network connections, may choose to defer image loading altogether. Accordingly, you should make sure your documents make sense and are useful, even if the images are completely removed.
The src attribute for the <img> tag is required; its value is the image file's URL, either absolute or relative to the HTML document referencing the image. To unclutter their document storage, HTML authors typically collect image files into a separate folder they often name something like ``pics'' or ``images.'' [URLs, 6.2]
For example, this HTML fragment places an image of a famous kumquat packing plant into the narrative text (see Figure 5-8):
Here we are, on day 17 of the tour, in front of the kumquat packing plant: <p> <img src="pics/packing_plant.gif"> <p> What an exciting moment, to see the boxes of fruit moving
In the example, the paragraph (<p>) tags surrounding the <img> tag causes the browser to render the image by itself with some vertical space after the preceding and before the trailing text. Text may also abut the image, as we describe in 5.2.6.4.
To the benefit of users, particularly those with slow Internet connections, the browser innovators at Netscape Communications have introduced the lowsrc companion to the src attribute in the <img> tag as a way to speed up document rendering. The lowsrc attribute's value, like src, is the URL of an image file that the browser loads and displays when it first encounters the <img> tag. Then, when the document has been completely loaded and can be read by the user, the Netscape browser goes back and retrieves the image specified by the src attribute.
Ostensibly, the lowsrc image is a low-resolution, abbreviated version of the final src image and which, therefore, loads faster by comparison to quickly give the reader an idea of its content until the final, higher-resolution image eventually replaces it onscreen. But the lowsrc attribute can also be used for some special effects.
For example, Netscape uses the lowsrc image's dimensions to reserve space in the document for both the lowsrc and src images, unless you explicitly allocate that space with the height and width attributes described below. Hence, if the dimensions of the image specified in the src attribute are different than those for the lowsrc image, the src image will be reduced, enlarged, stretched, and/or compressed to fit in the allotted space. Moreover, the lowsrc and src images needn't be identical, so you might take advantage of the delayed rendering of the src image for simple animation.
The lowsrc attribute is for Netscape version 2 only. Other browsers ignore it and only load the image specified by the src attribute. Netscape won't load either image if the user chooses not to auto-load images. In that case, both images will load in order when the user clicks the images button or clicks the image icon placeholder. No browser loads the lowsrc image only; you must include a src image, otherwise nothing will appear except the missing image icon.
The alt attribute specifies alternative text the browser may show if image display is not possible or disabled by the user. It's an option, but one we highly recommend you exercise for every image in your document. This way, if the image is not available, the user still has some indication of what it is that's missing.
The value for the alt attribute is a text string of up to 1024 characters, enclosed in quotes if you include spaces or other punctuation. The alternative text may contain entity references to special characters, but it may not contain any other sort of markup; in particular, no style tags allowed.
Graphical browsers ignore the alt attribute if the image is available and downloading is enabled by the user. Otherwise, they insert the alt attribute's text as a label next to an image placeholder icon. Well-chosen alt labels thereby additionally support those users with a graphical browser who have disabled their automatic image download because of a slow connection to the Web.
Nongraphical, text-only browsers like Lynx put the alt text directly into the content flow just like any other text element. So, when used effectively, the alt tag sometimes can transparently substitute for missing images. (Your text-only browser users will appreciate not being constantly reminded of their second-class Web citizenship.) For example, consider using the asterisk (*) character as the alt attribute alternative to a special bullet icon:
<h3><img src="pics/fancy_bullet.gif" alt="*"></h3> <h1>Introduction</h1>
A graphical browser displays the bullet image, while in a nongraphical browser the alt asterisk takes the place of the missing bullet. Similarly, use alt text to replace special image bullets for list items. For example, the following code:
<ul> <li> Kumquat recipes <img src="pics/new.gif" alt="(New!)"> <li> Annual harvest dates </ul>
displays the new.gif image with graphical browsers, and the text ``(New!)'' with text-only browsers.
The alt attribute lets you use even more complex text (see Figure 5-9):
Here we are, on day 17 of the tour, in front of the kumquat packing plant: <p> <img src=" pics/packing_plant.gif" alt="[Image of our tour group outside the main packing plant]"> <p> What an exciting moment, to see the boxes of fruit moving
The HTML standard does not define a default alignment for images with respect to other text and images in the same line of content, so you cannot absolutely predict how the mixture of text and images will look.[2] HTML images normally appear in line with a single line of text. Our common media like magazines typically wrap text around images, with several lines next to and abutting the image, not just a single line.
[2] Most of the popular graphical browsers normally insert an image so that its base aligns with the baseline of the text--the same alignment as that specified by the attribute value of bottom. Nonetheless, HTML document designers should assume that alignment varies between browsers and always include the desired type of image alignment.
Fortunately, HTML document designers can extert some control over the alignment of images with body-content text through the align attribute for the <img> tag. The HTML standard specifies three image-alignment attribute values: top, middle, and bottom. The developers of Netscape Navigator have added four more alignment attributes to that list: texttop, absmiddle, baseline, and absbottom. These are Netscape-only; other browsers ignore them. Two other special, nonstandard image alignments--left and right--are supported by all the extended browsers, including Netscape, Internet Explorer, and Mosaic. They let you embed images into the flow of text so that not just one but several lines of words will wrap around one and even fill the gap between two images.
The list below contains descriptions for the inline HTML image alignments. See Figure 5-10 for examples.
The top of the image is aligned with the top edge of the tallest item in the current line of text. If there are no other images in the current line, the top of the image is aligned with the top of the text.
The align=texttop attribute and value tells Netscape to align the top of the image with the top of the tallest text item in the current line. This is slightly different from the standard HTML top option, which aligns the top of the image with the top of the tallest item, image or text, in the current line. If the line contains no other images that extend above the top of the text, texttop and top have the same effect.
The middle of the image is aligned with the baseline of the text in the current line. Note that the baseline of the text is not anywhere near the middle of the text, so that it is not possible to align the middle of the image with the true middle of the text.
If you set the align attribute of the <img> tag to absmiddle, Netscape will fit the absolute middle of the image to the absolute middle of the current line. This is different from the common middle option, which aligns the middle of the image with the baseline--the bottom of the characters--of the current line of text. With absmiddle, the center of the image aligns exactly with the center of the text.
The bottom of the image is aligned with the baseline of the text in the current line. It is not possible to align the bottom of the image with the actual bottom of the current line. This type of alignment is most useful when inserting custom symbols and dingbats into a line of text.
The baseline value for the align attribute has exactly the same effect as the standard bottom option: it tells Netscape to align the bottom of the image with the baseline of the text line. Netscape's authors included this option simply because its name is more indicative of its effect on image alignment.
The align=absbottom attribute has Netscape align the bottom of the image with the true bottom of the current line of text: the bottom of the tail on a ``y,'' for example, rather than at the baseline of the text, which is the bottom of the ``v'' in the ``y'' character.
Use the top or middle alignment values for best integration of icons, dingbats, or other special inline effects with the text content. Otherwise, align=bottom usually gives the best appearance. When aligning one or more images on a single line, select the alignment that gives the best overall appearance to your document.
The left and right image alignment values tell the extended browsers to align an image against the left or right margin, respectively, of the current text flow. The browser then renders subsequent document content in the remaining portion of the flow adjacent to the image. The net result is that the document content following the image is wrapped around the image.
Figure 5-11 shows text flow around a left-aligned image:
<img src="pics/kumquat.gif" align=left> The kumquat is the smallest of the citrus fruits, similar in appearance to a tiny orange. The similarity ends with its appearance, however. While oranges are generally sweet, kumquats are extremely bitter. Theirs is an acquired taste, to be sure.
You can place images against both margins simultaneously (Figure 5-12) and the text will run down the middle of the page between them:
<img src="pics/kumquat.gif" align=left> <img src="pics/tree.gif" align=right> The kumquat is the smallest of the citrus fruits, similar in appearance to a tiny orange. The similarity ends with its appearance, however. While oranges are generally sweet, kumquats are extremely bitter. Theirs is an acquired taste, to be sure.
While text is flowing around an image, the left (or right) margin of the page is temporarily redefined to be adjacent to the image as opposed to the edge of the page. This means that subsequent images with the same alignment will stack up against each other. The following source fragment achieves that staggered image effect, shown in Figure 5-13:
<img src="pics/marcia.gif" align=left> Marcia! <img src="pics/jan.gif" align=left> Jan! <img src="pics/cindy.gif" align=left> Cindy!
When the text flows beyond the bottom of the image, the margin returns to its former position, typically at the edge of the browser window.
Have you noticed that you can't vertically center an image in the browser window with the align attribute? The middle and absmiddle values center the image vertically with the current line, but the image is horizontally justified depending on what content comes before it in the current flow and the dimensions of the browser window.
You can vertically center an inline image in the browser window, but only if it's isolated from surrounding content, such as by paragraph or line break tags. Then, either use the <center> tag or the align=center attribute in the paragraph tag to center the image. For example:
Kumquats are tasty treats <br> <center> <img src="pics/kumquat.gif"> </center> that everyone should strive to eat!
Use the paragraph tag with its align=center attribute if want some extra space above and below the centered image:
Kumquats are tasty treats <p align=center> <img src="pics/kumquat.gif"> </p> that everyone should strive to eat!
Browsers normally render images that also are hyperlinks (included in an <a> tag) with a two-pixel-wide colored border, indicating to the reader that the image can be selected to visit the associated document. Netscape and Internet Explorer let you change the thickness of that border with the border attribute to the <img> tag. The value of the border attribute is an integer equal to the border thickness in pixels.
Figure 5-14 shows you the thick and thin of image borders, as rendered from the following HTML source:
<a href="test.html"> <img src="pics/kumquat.gif" border=1> </a> <a href="test.html"> <img src="pics/kumquat.gif" border=2> </a> <a href="test.html"> <img src="pics/kumquat.gif" border=4> </a> <a href="test.html"> <img src="pics/kumquat.gif" border=8> </a>
You can eliminate the border around an image hyperlink altogether with the border=0 attribute within the <img> tag. For some images, particularly image maps, the absence of a border can greatly improve the appearance of your pages. Images that are clearly link buttons to other pages may also look best without a border.
Be careful, though, that by removing the border, you don't diminish your page's usability. No border means you've removed a common visual indicator of a link, making it less easy for your readers to find the links on the page. Browsers will change the mouse cursor as readers pass it over an image that is a hyperlink, but you should not assume they will, nor should you make readers test your borderless images to find hidden links.
We strongly recommend that you use some additional way with borderless images to let your readers know to click the images. Even including simple text instructions will go a long way to making your pages more accessible to readers.
Normally, a graphical browser determines the size of an image and, hence, the rectangular space to reserve for it in the display window, by retrieving the image file and extracting its embedded height and width specifications. This is not the most efficient way to render a document since the browser must sequentially examine each image file and calculate its screen space before rendering adjacent and subsequent document content. That can significantly increase the amount of time it takes to render the document and delay scanning by the user.
Netscape and Internet Explorer provide a more efficient way for HTML authors to specify an image's dimensions with height and width <img> attribute extensions. That way, the extended browser can calculate and reserve space before actually downloading an image, speeding document rendering. Both attributes require an integer value that indicates the image size in pixels; the order in which they appear in the <img> tag is not important.
A hidden feature of the height and width <img> extension attributes is that you don't need to specify exact image dimensions; attribute values can be larger or smaller than the actual size of the image. The extended browsers automatically scale the image to fit the predefined space. This gives you a down-and-dirty way of creating thumbnail versions of large images and a way to enlarge very small pictures. Be careful, though: The browser still must download the entire file, no matter its final rendered size, and you will distort an image if you don't retain its original height versus width proportions. Moreover, the full-size image probably will ruin the appearance of the document altogether if displayed by a nonextended browser like Mosaic.
Another trick with the height and width image attributes provides an easy way to flood-fill areas of your page and can also improve document performance. Suppose you want to insert a colored bar across your document. Rather than create an image to the full dimensions, create one that is just one pixel high and wide and set it to the desired color. Then use the height and width <img> extensions to scale it to the larger size:
<img src="pics/one-pixel.gif" width=640 height=20>
The smaller image downloads much faster than a full-scale image, and the width and height attributes create the desired bar after the tiny image arrives at the browser (Figure 5-15). Nifty, no? No, if the reader uses Mosaic or another nonextended browser, all they'll see is a one-pixel dot. So, again, don't forget these are special image extensions, not universally available to readers.
Although the height and width attributes for the <img> tag can improve performance and let you perform some neat tricks, there is a particularly knotty downside to using them. The extended browser sets aside the specified rectangle of space to the prescribed dimensions in the display window even if the user has turned off automatic download of images. What the user often is left with is a page full of semi-empty frames with a meaningless picture placeholder icon inside. The page looks terribly unfinished and is mostly useless. Without accompanying dimensions, on the other hand, the browser simply inserts a placeholder icon inline and usually sized to the surrounding text, so at least there's something there to read in the display.
We don't have an answer to this dilemma. We would, however, include extension attributes because we encourage any practice that improves network performance.
Graphical browsers usually don't give you much space between an image and the text around it. And unless you create a transparent image border that expands the space between them, the typical two-pixel buffer between an image and adjacent text is just too close for most designer's comfort. Add the image into a hyperlink, and the special colored border will negate any transparent buffer space you labored to create, as well as draw even more attention to how close the adjacent text butts up against the image.
The <img> extensions, hspace and vspace, supported by both Netscape and Internet Explorer, can give your images breathing room. With hspace, you specify the number of pixels of extra space to leave between the image and text on the left and right sides of the image; the vspace value is the number of pixels on the top and bottom. Figure 5-16 shows the difference between two wrapped images:
<img src="pics/kumquat.gif" align=left> The kumquat is the smallest of the citrus fruits, similar in appearance to a tiny orange. The similarity ends with its appearance, however. While oranges are generally sweet, kumquats are extremely bitter. Theirs is an acquired taste, to be sure. Most folks, at first taste, wonder how you could ever eat another, let alone enjoy it! <p> <img src="pics/kumquat.gif" align=left hspace=10 vspace=10> The kumquat is the smallest of the citrus fruits, similar in appearance to a tiny orange. The similarity ends with its appearance, however. While oranges are generally sweet, kumquats are extremely bitter. Theirs is an acquired taste, to be sure. Most folks, at first taste, wonder how you could ever eat another, let alone enjoy it!
We're sure you'll agree that the additional space around the image makes the text easier to read and the overall page more attractive.
The ismap and usemap attributes for the <img> tag tell the browser that the image is a special mouse-selectable visual map of one or more hyperlinks, commonly known as an image map. The ismap style of image maps is supported by all the graphical browsers. It may only be specified within an <a> tag hyperlink. [<a>, 6.3.1]
For example:
<a href="/cgi-bin/images/map2"> <img src="pics/map2.gif" ismap> </a>
The browser automatically sends the x,y position of the mouse (relative to the upper-left corner of the image) to the server when the user clicks somewhere on the ismap image. Special server software, the /cgi-bin/images/map2 program in the example, may then use those coordinates to determine a response.
The usemap attribute is supported by Netscape and Internet Explorer, version 2 or later. It's a client-side image map mechanism that effectively eliminates server-side processing of the mouse coordinates and its incumbant network delays and problems. Using special <map> and <area> extension tags, HTML authors provide a map of coordinates for the hyperlink-sensitive regions in the usemap image along with related hyperlink URLs. The value of the usemap attribute is a URL that points to that special <map> section. And the extended browser on the user's computer translates the coordinates of a click of the mouse on the image into some action, including loading and displaying another document. [<map> 6.5.3] [<area> 6.5.4]
For example, the following source specially encodes the 100-pixel wide by 100-pixel tall map2.gif image into four segments, each of which, if clicked by the user, links to a different document. Also notice we've included, validly, the ismap image map processing capability in the example <img> tag so that users of other, non-usemap-capable browsers have access to the alternative, server-side mechanism to process the image map:
<a href="/cgi-bin/images/map2"> <img src="pics/map2.gif" ismap usemap="#map2"> </a> ... <map name="map2"> <area coords="0,0,49,49" href="link1.html"> <area coords="50,0,99,49" href="link2.html"> <area coords="0,50,49,99" href="link3.html"> <area coords="50,50,99,99" href="link4.html"> </map>
Geographical maps make excellent ismap and usemap examples: Browsing a nationwide company's pages, for instance, the user might click their home town on a map to get the addresses and phone numbers for nearby retail outlets. The advantage of the usemap client-side image map processing is that it does not require a server or special server software and so, unlike the ismap mechanism, can be used in non-Web (networkless) environments, such as with local files or on CD-ROM.
Please read our more complete discussion of anchors and links, including image maps within links, in Chapter 6, Links and Webs.
You may combine any of the various standard and extension attributes for images where and when they make sense. The order for inclusion of multiple attributes in the <img> tag is not important, either. Just be careful not to use redundant attributes or you won't be able to predict the outcome.
Most of the extensions to HTML that Internet Explorer supports, including the various <img> tag attributes, were originally implemented and introduced to the Web by Netscape. However, the special controls, dynsrc, loop, and start attribute extensions for the <img> tag currently are unique to Internet Explorer. They let you embed an inline movie into the body content, just like an image.
It is a sorely needed innovation; movies otherwise require a separate helper application which the user must have installed and which displays the movie in a separate window (see 5.7). We, like many other Web aficionados, prefer integrated content.
However, the Internet Explorer movie extensions currently are very limited. They are not supported by any other browser and can only be used with Audio Video Interleave (AVI) formatted movie files, since that's the player format built into Internet Explorer and enabled through Windows 95. Moreover, recent innovations in browser technology, applets in particular, may make Internet Explorer's approach of extending the already overloaded <img> tag obsolete. See 5.6 for details.
You use the dynsrc attribute extension in the <img> tag to reference an AVI movie for inline display by Internet Explorer. Its required value is the URL of the movie file enclosed in quotes. For example, this is the tag and attribute for an AVI movie file entitled intro.avi:
<img dynsrc="movies/intro.avi">
The browser sets aside a video viewport in the HTML display window and plays the movie, with audio if included in the clip, similar to an inline image: in line with current body content and according to the dimension of the video frame. And, like common images, the <dynsrc> referenced movie file gets displayed immediately after download from the server. You may change those defaults and add some user controls with other attributes, as described below.
Because all other browsers currently ignore the special Internet Explorer attributes for movies, they may become confused by an <img> tag that does not contain the otherwise required <src> attribute and an image URL. We recommend that you include the <src> attribute and a valid image file URL in all <img> tags, including those that reference a movie for Internet Explorer users. The other browsers display the still image in place of the movie; Internet Explorer does the reverse and plays the movie, but does not display the image. Note that the order of attributes does not matter.
For example:
<img dynsrc="movies/intro.avi" src="pics/mvstill.gif">
Internet Explorer loads and plays the AVI movie intro.avi; all other graphical browsers will load and display the mvstill.gif image instead.
Normally, Internet Explorer plays a movie inside a framed viewport once, without any user controls. To add controls the user may manipulate with the mouse, include the controls attribute, without a value, in the respective <img> tag. VCR-like play, fast-forward, reverse, stop, and pause controls are provided to the user; if the clip includes a sound track, an audio volume is provided as well.
For example:
<img dynsrc="movies/intro.avi" controls src="pics/mvstill.gif">
adds the various playback controls to the video window of the intro.avi movie clip, as shown in Figure 5-17.
Internet Explorer normally plays a movie clip from beginning to end once after download. The loop attribute for the movie <img> tag lets you have the clip play repeatedly an integer number of times set by the attribute's value, or forever if the value is infinite. Of course, the user can cut the loop short by pressing the stop button, if given controls (see above), or by moving on to another document.
The following intro.avi movie clip will play from beginning to end, then restart at the beginning and play through to the end nine more times:
<img dynsrc="movies/intro.avi" loop=10 src="pics/mvstill.gif">
Whereas the following movie will play over and over again, incessantly:
<img dynsrc="movies/intro.avi" loop=infinite src="pics/mvstill.gif">
Looping movies aren't necessarily meant to annoy. Some special effects animations, for instance, are a sequence of repeated frames or segments. Rather than string the redundant segments into one, long movie that extends its download time, simply loop the single, compact frame or segment.
Normally, an Internet Explorer movie clip starts playing as soon as it's downloaded. You can modify that behavior with the start attribute in the movie's <img> tag. By setting its value to mouseover, you delay playback until the user passes the mouse pointer over the movie viewport. The other valid start attribute value, fileopen, is the default: start playback just after download. It is included because both values may be combined in the start attribute to cause the movie to automatically playback once after download, and then whenever the user passes the mouse over its viewport. Add a value-separating comma, with no intervening spaces, or else enclose them in quotes, when combining the start attribute values.
For example, our by-now-infamous intro.avi movie will play once when its host HTML document is loaded by the user, and whenever he or she passes the mouse over the movie's viewport:
![[Graphic: Figure 5-8]](figs/uhtml0508.gif)
![[Graphic: Figure 5-9]](figs/uhtml0509.gif)
![[Graphic: Figure 5-10]](figs/uhtml0510.gif)
![[Graphic: Figure 5-11]](figs/uhtml0511.gif)
![[Graphic: Figure 5-12]](figs/uhtml0512.gif)
![[Graphic: Figure 5-13]](figs/uhtml0513.gif)
![[Graphic: Figure 5-14]](figs/uhtml0514.gif)
![[Graphic: Figure 5-15]](figs/uhtml0515.gif)
![[Graphic: Figure 5-16]](figs/uhtml0516.gif)
![[Graphic: Figure 5-17]](figs/uhtml0517.gif)
<img dynsrc="movies/intro.avi" start="fileopen,mouseover"
src="pics/mvstill.gif">
Treat Internet Explorer inline movies as you would any image, mixing and matching the various movie-specific, as well as the standard and extended <img> tag attributes and values supported by the browser. For example, you might align the movie (or its image alternate, if displayed by another browser) to the right of the browser window:
<img dynsrc="movies/intro.avi" src="pics/mvstill.gif" align=right>
Combining attributes to achieve a special effect is good. We also recommend you combine attributes to give control to the user, when appropriate. For instance, if you set up a movie to loop incessantly, you should also include the controls attribute so the user can stop the movie without having to leave the HTML document.
As we stated in 5.2.7.4, by combining attributes you can also delay playback until the user passes the mouse over its viewport. Magically, the movie comes alive and plays continuously:
<img dynsrc="movies/magic.avi" start=mouseover
loop=infinite src="pics/magic.gif">
