The original image, samerica.jpg
The overlaid image map with hot spots defined
As with the other similar pages on this site, this page is designed to be easily printed out and read offline, away from the computer. If you are trying to follow this lesson online you will find it much more convenient to return to the full lesson 7 menu.
SPECIAL NOTE ABOUT THIS PAGE: This lesson deals with techniques which make changes on the screen. It is obviously impossible to reflect these on the printed page. You may still find this "printer-friendly" version of the lesson useful, particularly with the coding of image maps and multipart images, but on the whole I suggest you would benefit more from following the whole lesson through online.
Contents
The title of this page rather underestimates the content of the lesson. As well as the technique of image maps, this lesson discusses other techniques for manipulating images on the screen. Because graphics "made" the WWW what it is today, it's unsurprising that programmers, developers and commercial interests all sought ways to enhance the basic graphics capabilities of browsers. This lesson deals with these. But do remember that in the end, these are just additions to the basics - web pages can be perfectly good without getting anywhere near these techniques. You should always remember that not all web surfers can or do load graphics. Nevertheless, these are essential techniques to learn if you have any intentions of being a fully-fledged web designer.
As we saw in lesson 5, placing images in your web page involves nothing more complex than adding an <IMG> tag, at least in technical terms - though, as you should remember, there was a lot more thought needed about what made a good image and why it was being placed on screen. But although all the techniques we'll look at in this section are nothing more than elaborations on the <IMG> tag, it's a tag with the potential for a lot of elaboration. There are two main ways this can take place:
As we'll see, these two improvements can also be combined. Once you start using images in this way you will be able to achieve quite professional-looking effects on your web pages.
Let's take the second of those two techniques first: making different parts of an image behave in different ways. The most common use of this is when an image is a link. Through associating what is known as a map with an image file, you can make different parts of the image act as a link to different files, or different parts of the same file. Here is the first situation where it is impossible to show you this on the printed page: do have a look at http://www.leeds.ac.uk/acom/html/subj_imgmap_intro.cfm to see one in action.
Experience has shown me that the best analogy for the image map is one of those transparencies that you use on overhead projectors. Imagine a map of South America in an atlas. You could lay a transparency over the top of the atlas and use a felt-tipped pen to draw around the countries used here (or indeed all of them). Imagine then that those felt-pen outlines are turned into links or, in correct terminology, hot spots. You therefore keep the image as it was before (left), but overlay it with a map (right) in which some hot spots have been drawn out and linked to different parts of the file ext_countries.cfm (only two shown here for clarity):
| |
The original image, samerica.jpg | The overlaid image map with hot spots defined |
Though the hot spots clearly corresponded to "shapes" in the original image (e.g., the countries' borders), this didn't have to be the case. I could have equally applied a map that had three or four circular hot spots drawn in essentially random locations. The point is that though the original image and the map will have some relationship with each other, they remain essentially separate entities, just as would a page in an atlas or other book, and a transparency laid on top of it. The fact you can see the former through the latter is not really relevant.
The sections on the USEMAP attribute (7.2), the <MAP> tag (7.3) and the <AREA> tag (7.4) describe how to create image maps and code them within HTML. This section discusses a few of the ways the technique can be used well - and, as ever, used badly.
Beyond the fact that they need to be used as links, the applications of image maps are unlimited - because, as I've said, you can take any image and turn it into a map, and you can draw the hot spots where you like. But the most common ones are as follows:
As I said, the possibilities are huge. However, there are some definite drawbacks to doing things this way, and you should bear these in mind.
Do remember that not all users can - or want to - see images. And also, if the shapes of hot spots do not obviously correspond to shapes in the underlying image (or even sometimes if they do), there is no outward indication a hot spot is there unless and until the cursor is placed over it. Was it easy to tell (before looking at the linked file) which five South American countries I'd used? I'll bet most of you ended up at Brazil or Argentina first; how many of you ended up reading about Ecuador first?
Between them these two factors make it essential that you provide some kind of alternative way of reaching the relevant information (even if nothing more sophisticated than the scroll bar). The image map is a useful way of relating links to some kind of visual guide; such as the example of linking information to a real map, or a diagram. But if used as a gimmicky menu alone, you run the risk of preventing people ever finding half your site, if they either miss a particular hot spot, or can't view the image in the first place. (Though the image and the map are essentially separate, the map won't work without the image.) This factor means that image maps, though they can be great if well used, are and always will be garnish. More is said about this in lesson 10.
As well as the three sections directly related to image maps, there is also a page on the related technique of multipart images (7.6) which I've mentioned a few times so far. This can be combined with the technique known as rollover images (7.5) to produce some quite sophisticated graphical effects; and if learning about rollovers you will also need to learn how to preload images (7.7) using JavaScript.
Only the introductory lessons (1-5) had actual exercises for you to perform, but I hope this lesson and the next give you some inspiration. Remember, though, it is a bad idea to make an image map the only means of navigating around your site or of accessing certain information. They can be very irritating if used badly, particularly when important hot spots are simply impossible to find because they're too small and/or they don't particularly relate to features on the underlying image. You're required to construct an image map in your coursework to display your understanding of the techniques, but in other pages you may go on to write, they are far from obligatory: think about how to use them well. The same goes for rollover images, and indeed every other one of these advanced techniques.
Remember what I said about the "transparency" analogy. Putting USEMAP in your <IMG> tag basically says, "there's an image map (transparency) which I want the browser to lay over this image". This doesn't affect in any way the rendering of the image, so all other attributes (ALT, HEIGHT/WIDTH, SRC, possibly others such as BORDER) can appear as before. (It is a good idea to use HEIGHT and WIDTH when creating images as maps, as you do need to ensure the browser renders the image in the size you expect. Although it usually will anyway, best to be 100% sure.) USEMAP then takes a value of the name of the map being used.
(Sometimes you see ISMAP, but this attribute is involved in a slightly-different technique known as server-side image maps. As it is unlikely you will have administrator access to a server, you will not be able to use these therefore I am not teaching them. USEMAP is for client-side image maps. The "client" is the reader of the page; what "client-side" means is that the image map is applied by the reader's computer (via the techniques I'm about to show you) rather than the host computer. But all in all, and having dragged you screaming to the end of this parenthetical note, I wouldn't worry about it...)
As you'll see on the very brief section (7.3) about the <MAP> tag, image maps take the NAME attribute in the same way as anchor tags (and other features of HTML we haven't yet investigated). And remember that when you want to point to a NAMEd anchor, you need to use the hashmark (#) character to refer to that NAME. The same applies in USEMAP. These are the only additions you need to make to the actual <IMG> tag in order to turn it into a map.
So, to refer back to the example used on the introductory page, this image has the following tag:
<IMG SRC="samerica.jpg" ALT="A map of South America"
HEIGHT=300 WIDTH=218 USEMAP="#samerica">
I haven't actually defined the code of the map, samerica, in this HTML file so there aren't any hot spots on this image. I'll build it up as we go through the next few pages. Note also that the inclusion of ISMAP/USEMAP gives the image a "link border", even though it's not enclosed within <A> tags. To prevent this, add BORDER=0 to the <IMG> tag. |
|
Do note that while you're limited to one map per occurrence of an image, there's no reason why you couldn't duplicate an image on another web page - or even, further down the same web page - and have an entirely different map apply to it. All you do is change the value of USEMAP. Keep that analogy of the image and the transparency in your mind and remember that you can always lay a different transparency over the image, if one's prepared.
It's almost not worth giving this tag a separate section, but I'll do so if only to separate it out from the more important <AREA> tag and therefore avoid confusion, well, hopefully anyway.
The <MAP> and </MAP> tags - and you do need the closing tag in this case - tell the browser where a particular image map (description of a "transparency") begin and end. In practice, they act as the container for all necessary <AREA> tags. <MAP> only takes one attribute, and it's an obligatory one - NAME. As in anchor tags, NAME can take whatever value you like, but avoid words that you know have another meaning in HTML or can be the values of attributes ("yes", for instance). In practice I usually end up calling it by the name of the image to which it refers, minus the extension - but remember what I said at the end of the previous section, that two completely different maps could in principle apply to the same image (though not the same occurrence of an image).
To continue building up our example map, then:
<IMG SRC="samerica.jpg" ALT="A map of South America"
HEIGHT=300 WIDTH=218 USEMAP="#samerica">
<MAP NAME="samerica">
[...<AREA> tags go here...]
</MAP>
Do note that although it's general practice to place the <MAP> immediately following the image to which it refers, there is absolutely no reason at all why this has to be the case. You could put it right at the end of the document (or, indeed, at the beginning) if you wanted to get it out of the way. It's probably more helpful to yourself to keep them in relatively close proximity, however.
This tag is the real meat of image maps. It won't work without the others - the <MAP> tags have to enclose <AREA> tags or they won't work, and you then need the USEMAP attribute to point to the map. But it's through the <AREA> tag that you "draw" out the hot spots; the equivalent of making those felt-pen marks on the overhead transparency. For each hot spot you want to trace, you need an <AREA> tag. (There is no closing tag.)
The first thing we need to tell the browser, then, is the SHAPE of the hot spot. SHAPE wasn't in capitals for emphasis alone, but because it's the name of the relevant attribute in this case. It can take three values, though each of the three can appear in shorthand or the full version, as given in the table below. The next thing you need to tell the browser is the co-ordinates of the shape, in other words, where it actually is on the "transparency". Have a look at the table first, and then I'll explain how the co-ordinates can be established.
Full SHAPE value | Shorthand value | COORDS |
| circle | circ | x, y, r |
| rectangle | rect | x1, y1, x2, y2 |
| polygon | poly | x1, y1, x2, y2, x3, y3.... xn, yn |
|
The co-ordinates of a point on an image are worked out in terms of pixels. Those who remember their GCSE maths should know that the x axis is the horizontal one, the y axis the vertical. However, unlike Cartesian co-ordinates, point (0, 0) is in the top left of an image. The map of South America, as should be clear from the HEIGHT and WIDTH attributes, is 218 pixels wide (x axis) and 300 pixels high (y axis), so the bottom right pixel is (218, 300). The other point I've marked on the picture here - which happens to be, roughly, the northernmost tip of Bolivia - has its own unique pair of co-ordinates, and so indeed does every other one of the 65,400 pixels in this image. |
 |
Elaborating on the table above, then, the COORDS attribute takes the following values depending on the SHAPE:
To actually work out where co-ordinates lie, you will need to load the image up into a graphics editor such as Paint Shop Pro or Photoshop. These have "information windows" which, when you place the cursor over a point in the image, will give you the x and y co-ordinates of that point. It doesn't take that long to write these down and work out where your hot spot shapes are located. However, there's an even quicker way, if you have access to Dreamweaver - indeed, this is the one aspect of web design where Dreamweaver saves you a lot of bother.
 | Simply load your page up into Dreamweaver, head for the image which you wish to associate with a map, and "expand" the Properties Window (this may well be gobbledegook if you've never used Dreamweaver, but hey, that's why Help menus exist). You will see something like the screen shot to the left and it should be fairly clear what's going on: choose your shape and then simply click around the image until the hot spot is created, as in the example of Bolivia here. Add the hot spot's destination in the "Link" box. Once all are done, come back out of Dreamweaver and you will see that it has created the map for you, with all COORDS in place. This is a great time-saver. |
Finally, you will of course need to tell the browser where the hot spot links to. Normally this is done with an HREF attribute in the <AREA> tag, in the same way as for <A> tags. If you want to use a TARGET attribute (see lesson 10) for whatever reason, stick that in there as well. You now have all you need to create your own maps.
There are some other tags which can be used on image maps. To create a hot spot that doesn't actually link anywhere, instead of the HREF attribute, put NOHREF in instead (this takes no values). ALT is also an attribute which can appear in <AREA> tags, giving different floating captions over different parts of the image. You might even try using onClick events to produce alerts or other effects - see lesson 8.1.
Trouble is that these are shakily supported by browsers at the present time. Using NOHREF does create a hot spot but means that the cursor will not change to a "hand" when over that hot spot. This means the spot could be easily missed. Netscape doesn't support the ALT attribute in <AREA> tags either, which means that a NOHREF hot spot in Netscape is effectively nonexistent.
In the online version of this lesson I present another example map here which illustrates some of these points: you're best off returning to http://www.leeds.ac.uk/acom/html/subj_area_tag.cfm#here amd having a look at it.
Remember - any image can be turned into an image map. Of course, not all do so logically, but that's not the point. It's not the image that matters, it's the "transparency" you lay over it. The best uses of image mpas are when information you want to present is directly related to different parts of an image, and this is why it is particularly appropriate for use with images such as (actual) maps, blueprints and diagrams: types of image which are already presenting graphical information. Photographs are usually more inherently illustrative, rather than informative, and it is more likely therefore that using a map on a photograph will be gratuitous or contrived. But that doesn't mean there aren't creative uses here. Just remember: always provide some alternative means of reaching the information in question for those that cannot or do not want to view images.
Once again this offline lesson is constrained by its format. To see rollovers in action, have a look at http://www.leeds.ac.uk/acom/html/subj_rollovers.cfm .
A "rollover" image is one that can change its state on screen. Usually this happens when the user places his or her mouse pointer over the image. To make a rollover, you need two images. In the example referenced above, they are as follows (reduced in size):
 |  | |
This is an image called madbaby.jpg | This is an image called madbaby2.jpg |
It is madbaby.jpg that is first placed on the page in the normal way, using a standard <IMG> tag. What you must then do is tell the browser to swap the images over when a particular event happens: in this case, an "onMouseOver" event. This is another simple piece of JavaScript (see lesson 8), placed in a fashion that makes it resemble an attribute. It has to be located in <A> tags that surround the image, as follows:
<A HREF="#" onMouseOver="document.baby.src='madbaby2.jpg';"
onMouseOut="document.baby.src='madbaby.jpg';">
<IMG SRC="madbaby.jpg" NAME="baby" BORDER="0"
ALT="Rollover image demo">
</A>
Because the best way of making this technique work is to do so within a link, but because the image is not meant to serve as an actual link, the link is what is known as a dummy. The HREF="#" suggests it is an anchor link, but there is no destination. I have also included BORDER=0 within the <IMG> tag to ensure the image renders without an unnecessary border. (Note that HREF="#" does in fact have a destination - it will return you to the top of any given page. If the rollover image is not an actual link but is not at the top of a page, you may need to define an anchor link at the image in question.)
As to the rest of that HTML, the key to the rollover technique is the NAME attribute. Just as in anchor tags and the <MAP> tag, by giving an HTML element a NAME, you are enabling the browser to refer to that element from another part of the HTML file. As it happens, the reference is made in the immediate proximity of the NAME in this case - e.g., the <A> tag immediately surrounding the NAMEd image - but it doesn't have to be, as I'll suggest below. Anyway, the onMouseOver "attribute" consists of some JavaScript which basically says, "take the element named baby in the current document and change its SRC to the file madbaby2.jpg when the mouse is over that element." All rather logical, when you put it like that.
The onMouseOut event changes things back once you're done. Note that there's nothing stopping you leaving the second image in place, by omitting the onMouseOut portion; nor would there be anything stopping you loading up a third image when the mouse moves off, instead of reverting to the original.
The tag in which the onMouseOver event is located doesn't have to be actually around the image being changed. It's the NAME which draws the two into a relationship, not their being nested. Again you should return to the online version of this page and have a look at the example (the menu with the arrows). Note that although the three arrows are identical in terms of the two images which comprise them, they each have different NAMEs. They have to, otherwise placing the mouse over any one of the links would cause all three arrows to change simultaneously. This time, the rollover image is not itself a link; rather, the onMouseOver and onMouseOut events are placed within the active <A> tag surrounding the nearby text. But there's no reason why the event and the image being changed even need to be particularly near each other, though obviously they have to be on screen at the same time, otherwise the procedure is nearly pointless.
As to how to create these images, use a graphics package! To go into detail is beyond the scope of this web site, but once I'd got madbaby.jpg, it was only the work of about five minutes with Paint Shop Pro to create madbaby2.jpg, and I'm pretty inept with graphics packages, to tell the truth. Be creative!
Of course you could "roll" between two images that were only vaguely related, if at all. I think this is a waste of time, though; if you want to show two images on a page, show them both in the ordinary fashion. And note the distortion which will occur if the two images are not the same size. No, if you're going to do this sort of thing, have two images that are closely related and generally alike, so the rollover has visual impact and isn't gratuitous.
A further development of this idea comes in the next section about multipart images. If using the technique for any image that is larger than a few Kb - that is, almost all images - you should really preload the image (7.7), as if the new image isn't in your cache, the time taken to load it up can completely spoil your use of this technique.
A final word of warning - do give the reader cause to place their mouse over a rollover image. If there's one there, tell them about it! Also, don't "hide" important information under a rollover. It's very irritating to come to a page and find that the author has gratuitously hidden half the content simply to show off their mastery of the rollover technique. (Some critics of this style have called it "mystery meat" - like the "meat" in certain take-aways, you don't know what it is until you've taken a bite, and then you might not like it.) As ever, if you're going to do this sort of thing, have a point. But it's very common, and once you've got the two images, quite easy to produce eye-catching effects. It's main use is in livening up your menu bars, and more detail comes on this in lesson 10.
Multipart images are a sort of alternative to image maps, though in practical terms the technique is quite different. Nevertheless, the end effect is similar: that different parts of an image can be made to behave in different ways. In fact, professional web designers are more likely to use this version of the technique than the "ordinary" image map. There are distinct advantages to this technique over image maps:
A small disadvantage to the technique is that you cannot work with anything other than rectangular sections, because to "slice up" the image, you need a table. However, with some ingenuity, this isn't really a big problem. The main disadvantage with this technique is that it is a damn sight more difficult than image maps. You will need a graphics editor not only to establish the co-ordinates of each different section of the image, but also to physically break the image up around these co-ordinates, saving each "slice" of the image into a separate file. These files are from then on treated as completely separate images, but they are pieced back together into the complete image with a table.
The easiest way to explain this is to show you a couple of examples. In the first place, the technique has been used purely for decoration. It looks fairly straightforward, but the only other way would be to present the central text as part of the image, and that would come complete with all the disadvantages of presenting text as an image: nor could you easily code the link. The main disadvantage here is that it will break up if and when text is resized on the screen, unless you fix the text size exactly in the style sheet (or, as here, in a STYLE attribute). This is probably one of those rare occasions when it's better to do that.
Firstly we have the original image:
Note that the central space inside this "frame" is transparent, so the background colour shows through.
I then create four separate images by "slicing" this image up in a graphics package: all you need to do is make a rectangular selection (a "marquee"), then copy and paste the selection into new image files. Be precise though! As you'll see, the dimensions of each of these slices match. (To see these, check out the ALT attribute.) It's a very good idea to note down their heights and widths in pixels, anyway: as you'll see when we perform the next step, constructing the table. Note also that I have deliberately extended the selection beyond the frame itself, to ensure that the text in the centre is "padded" out away from the frame. (There were other methods I could have used here but this seemed the simplest.) I've therefore enclosed the images below in borders so you can see their exact extent.
 |  |  |
 |
Incidentally, I don't mean to suggest this is a piece of cake. Even after you've had some practice at it, it can still be a frustrating experience ensuring that you have acquired every last pixel: missing just one row or column of them can leave you with an untidy-looking final result. If at first you don't succeed though, try try again...
OK, now it's time to stick them all back together - with the added text in the middle. I'll show you the end result first:
| ||
|
Follow this link to the photo gallery | |
| ||
This has been constructed using a table with five cells, the central one of which is text, but the other four of which are filled with the parts of the image. See the code; and do remember that the key to understanding tables is to look at the structure first, what's inside the cells afterwards. There is a further summary, of all the various stages involved here, after the second example which follows.
<TABLE WIDTH=248 ALIGN=center BORDER=0 CELLPADDING=0 CELLSPACING=0>
<TR>
<TD WIDTH=248 COLSPAN=3>
<IMG SRC="picframetop.gif" HEIGHT=55 WIDTH=248 ALT=" ">
</TD>
</TR>
<TR>
<TD WIDTH=62>
<IMG SRC="picframeleft.gif" HEIGHT=129 WIDTH=62 ALT=" ">
</TD>
<TD WIDTH=125>
<P STYLE="font-family: Lucida Handwriting, cursive;
font-size: 16pt; text-align: center">Follow this link
to the <A HREF="gall.cfm" STYLE="font-family: Lucida
Handwriting, cursive; font-size: 16pt;">photo gallery
</A></P>
</TD>
<TD WIDTH=61>
<IMG SRC="picframeright.gif" HEIGHT=129 WIDTH=61 ALT=" ">
</TD>
</TR>
<TR>
<TD WIDTH=248 COLSPAN=3>
<IMG SRC="picframebottom.gif" HEIGHT=55 WIDTH=248 ALT=" ">
</TD>
</TR>
</TABLE>
I deliberately placed a link inside that picture frame to suggest the advantage of doing it that way, rather than just using an image to do the whole job: which is of course easier, but somehow less attractive. Bearing in mind that we can use images as links though, another use of the technique suggests itself.
The second example therefore combines the technique with rollovers to produce another form of image map. Move the cursor over the sections of the image below, and move the mouse over it to see what effects this has. Note that there is a delay between moving the mouse over and loading the image, although if you are viewing this from university it won't be a very long one - you'd notice it from home though. Ideally, this unsightly delay would be removed by preloading the image. However, this would complicate matters still further at this stage, so I will let it pass here and instead direct you to the section on preloading (7.7 below) where you can find out how to cure this problem.
The HTML which has rendered this image follows. However to get the full impact of this technique you do need to see this in situ, online, so please have a look at http://www.leeds.ac.uk/acom/html/subj_multiparts.cfm.
 | |
 |
 |
 |
|
<TABLE BORDER=0 CELLPADDING=0 CELLSPACING=0 WIDTH=176>
<TR>
<TD COLSPAN=2>
<A HREF="ardnamurchan.cfm"
onMouseOver="document.north.src='mapnorthw.gif';"
onMouseOut="document.north.src='mapnorthb.gif';">
<IMG SRC="mapnorthb.gif" WIDTH=176 HEIGHT=80 BORDER=0
ALT="North: Sanna Bay, Ardnamurchan, Scotland" NAME="north"></A>
</TD>
</TR>
<TR>
<TD>
<A HREF="silverdale.cfm"
onMouseOver="document.west.src='mapwestw.gif';"
onMouseOut="document.west.src='mapwestb.gif';">
<IMG SRC="mapwestb.gif" WIDTH=88 HEIGHT=90 BORDER=0
ALT="West: Silverdale, Morecambe Bay" NAME="west"></A>
</TD>
<TD>
<A HREF="scarborough.cfm"
onMouseOver="document.east.src='mapeastw.gif';"
onMouseOut="document.east.src='mapeastb.gif';">
<IMG SRC="mapeastb.gif" WIDTH=88 HEIGHT=90 BORDER=0
ALT="East: Scarborough. Yorkshire" NAME="east"></A>
</TD>
</TR>
<TR>
<TD COLSPAN=2>
<A HREF="ashdown.cfm"
onMouseOver="document.south.src='mapsouthw.gif';"
onMouseOut="document.south.src='mapsouthb.gif';">
<IMG SRC="mapsouthb.gif" WIDTH=176 HEIGHT=88 BORDER=0
ALT="South: Ashdown Forest, Sussex" NAME="south"></A>
</TD>
</TR>
</TABLE>
So, once again the various stages involved in creating this effect were as follows:
|
| ||||||
All in all, this technique is not easy, but definitely worth it if you can pull it off. I've seen entire pages arranged like this - though a problem is, of course, that it fixes the size of portions of your page in pixels, precisely. (What a lot of Ps that was.) Change the screen or window size and you could lose a lot of it. Nevertheless, it's a powerful and professional technique; for just about the best I can personally manage here, have a look at the game on http://www.leeds.ac.uk/acom/html/ext_fairytale.cfm.
With all the image-changing tricks we've used so far, whether with full or multipart images, there is one big problem. This is that images take time to load, and the browser viewing the page does not start to load the images until it is instructed to. The way around this problem is to ensure that the images in question are in the viewer's cache before they are required. We did discuss one trick on the page about the cache (6.8): that is, loading a "super-dense", 1 × 1 pixel version of the image while the user was happily reading something else. But that might not be possible all the time, and in any case, it's a bit of a cheat. Much better to use JavaScript to preload the image into the cache.
One problem with trying to convince university students of the need for this is that at uni, download times are very fast. It may well be, then, that when you come to the examples below, you'll ask, "what is he going on about?" as the download times for each example will be negligible. I suggest, if possible, you look at this page from a home PC if you remain unconvinced. I also suggest, while we're on the subject, that you look at all your course work web site on a home PC, or ask a friend/relative with Net access to do so for you. One of the tests we run when marking your sites is to look at them from a PC, modem and browser that between them are getting pretty clunky in their old age - I know this, as they're mine! So keep me in a good mood, and reduce my phone bill when marking your work!
This is the first time we will actually encounter proper JavaScript, as opposed to JavaScript events (like onMouseOver). The main lesson on JavaScript is coming up shortly (lesson 8), but even so, a lot of this will still look like hieroglyphics at this stage. Don't worry about it though: just faithfully repeat it in your code - you can find out what it actually means soon.
To get an images into the viewer's cache before they've actually seen it, you will have to include in the <HEAD> of your HTML file a JavaScript routine which pre-loads any images which are not visible when the page is first loaded. (There is no point in pre-loading images which appear when the page is first loaded, as the very act of displaying the images ensures that they arrive in the viewer's cache.) A further advantage of this method is that you can include in the image pre-loading script a line which checks before running the script whether or not the viewer's browser can handle image changing, which means that people with older browsers which perhaps cannot deal with image objects will not attempt to run the script - making your page backwards compatible with older browsers.
It will help to see this example online, and should check out http://www.leeds.ac.uk/acom/html/subj_preloading.cfm at this point.
The basic image pre-loading (and changing - whilst we are putting stuff in the HEAD of the document we might as well put it all there) script looks like this:
<script type="text/javascript">
<!--
no1 = new Image(379, 412);
no1.src = "jupiter.jpg";
no2 = new Image(379, 412);
no2.src = "jupiterpainted.jpg";
function changeimage (imgTagName,imgObj)
{
if (document.images)
{
document.images[imgTagName].src = imgObj.src
}
}
// -->
</script>
It shouldn't be too hard to adapt this to your requirements - remember it goes before the </HEAD> tag. The script starts by loading the images. The first image to be loaded is called jupiter.jpg, and (like the other) it is 379 pixels tall by 412 pixels wide. This image is given the label "no1", for reference. The next image is called jupiterpainted.gif and is given the label "no2". The part of the script which actually loads the images is the no1.src = "jupiter.gif"; which updates the source of the image. The rest of the script, as you may be able to guess, actually does the image changing. The function takes two values (imgTagName, and imgObj), and after checking to see that the browser can handle image objects (which is what if (document.images) does) it says 'swap whatever the source for imgTagName is with the source for whatever imgObj is'. (.src in a JavaScript or HTML context stands for source). This new script means that in order to change images all you have to do is call the function changeimage with the correct parameters - namely, two images which are mentioned in the preloading bit of the script.
So, to invoke the script above (which is also in the head of this document) all we need to do is to include the following code in our HTML file (the link could be a real link even though I have left it as a dummy here):
<A HREF = "#"
onMouseOver = "changeimage('planet',no2)"
onMouseOut = "changeimage('planet',no1)">
<IMG NAME="planet" BORDER=0 SRC="jupiter.jpg" WIDTH=379
HEIGHT=412></A>
As to what the effect of all this is, have a look at the online version of this page.
Ideally you should preload all images that are involved in rollovers, unless they are very small and/or you know they will already be in the cache.
End of lesson 7.
Material on this site is © Drew Whitworth and ACOM, 2002. Permission will usually be given to reproduce material from this site for non-commercial purposes, if credit is given. For enquiries, e-mail Drew at drew@comp.leeds.ac.uk.