I realize that this is another unplanned change that I’m making without getting a consensus or having it added to the spec or whatever.
— Marc Andreessen, referring to the addition of Image Maps to Mosaic in
If you didn’t live through this particular part of Internet history, an image map is a way of making regions of an image links. For example, I might have a picture of the founders of Apple, and using an image map, when you click each founders head you are taken to a page on their history.
Image maps were historically even used to create entire websites. A designer would make an image of what the site should look like, and then a developer would make an image map on top of that image which allowed each button to take the user to the correct place. This is now frowned upon.
Server-side Image Maps
Mosaic version 1.1 added support for ‘server-side’ image maps in 1993. They are ‘server-side’ in that the browser doesn’t actually make any decisions based on where you click the image. Instead, the browser sends to your server the coordinates of the click, and it’s up to you use that information as you see fit.
For example, I might create an image map:
<a href='/cgi-bin/handle-map-click.pl'> <img src="map.gif" ismap> </a>
When that image is clicked, the browser will send the user to the URL with coordinates appended:
(This predated the complete adoption of the modern GET parameter syntax proposed by Marc Andreessen in 1993)
This was added by Mosaic during a period of intense iteration, where new features were being added in response to user requests regularly (to the great consternation of the standards community). The
<IMG> tag itself had only been added in February of 1993.
This image map format makes a certain amount of sense. It’s very flexible, in that you could handle the information however you’d like inside your server. It also gracefully degrades, as if the browser doesn’t understand the
ismap attribute, you’ll just get a request without coordinates, and can handle that as well.
Unfortunately it had some issues. For one, relative links didn’t work, because your server-side script didn’t know the original web page you had been on. Also, it was impossible to cache the linked-to page, because your browser didn’t know if clicking a different area of the image would take you to the same place or not. Finally, actually setting up these image maps was cumbersome. You had to run a script on your server, and update it whenever your image changed.
Tim Berners-Lee made the interesting proposal that rather than sending pixel values, the browser should send a float value from
0.0-1.0, representing where the user had clicked relative to the image’s height and width. This would allow browsers to send different sized images based on the bandwidth and resolution of the client while using the same server-side code. (The actual implementation for this dynamic image sizing wouldn’t enter the HTML5 spec for more than a decade though).
The spec was evolved to transition to using real GET parameters in HTML+ (which was the codename for the work happening on HTML around 1993). The
ismap attribute also migrated onto the
fig element, which was seen as a better replacement for
<fig ismap src="weather.gif"> <caption>Click on your area for a local forecast</caption> Todays weather map for the US. </fig>
The spec also allowed for applications where you would click and drag a region on the image, sending you to a url suffixed with:
The spec also, very interestingly, included support for placing buttons on top of images, similar to how an annotation in YouTube works today:
<FIG SRC="test.gif"> <CAPTION>Click on the triangle or the rectangle</CAPTION> A line drawing with a <A SHAPE="0.35,0.1&0.1,0.8&0.35,0.8" HREF="button1.html"> triangle</A> and a <A SHAPE="0.5,0.25&0.5,0.5&0.8,0.5&0.8,0.25" HREF="button2.html"> rectangle</A> </FIG>
Which would be rendered as:
It became clear though that doing the image mapping on the client was a better plan. There was originally some resistance, specifically from people who wanted image areas to be mappable to complex shapes like polygons, circles, and arbitrary bitmasks. This was easier to do when you controlled the server, than in a general-purpose client-side implementation.
Client-side Image Maps
It wasn’t until HTML 3.2 was introduced in January of 1997 that the ‘modern’ implementation of image maps was introduced. This is the implementation you are more likely to have encountered (hopefully earlier) in your career.
The idea is you define an image map using the
<map> tag, giving it a unique identifier. You then use the
usemap attribute to bind your image to that map:
<img src="image.png" alt="Website map" usemap="#mapname" /> <map name="mapname"> <area shape="rect" coords="9,372,66,397" href="http://en.wikipedia.org/" alt="Wikipedia" title="Wikipedia" > </map>
area elements can use
rect for rectangles,
poly for arbitrary polygons, and
circle for... circles.
alt attribute functions similar to that of a link, providing something for screen readers to read. The
title attribute can be rendered by the browser as a tooltip when the user hovers over that region of the image.
How Image Maps Were Used
Client-side image maps led to the proliferation of all sorts of useful image maps, like this example from Wikipedia:
It also led to all sorts of terrible implementations, most notably sites which are composed of one giant image which you have to click on randomly to navigate (there’s a term for that it turns out).
Fortunately for us, there are still examples of sites like this today.
Ultimately, the web accessibility and UX movements moved us towards using ‘text’ to represent navigation, as crazy as that might sound. Search engines also pressured websites to move away from storing content in images to get the elusive magic of ‘SEO’. Finally, advances in CSS made it possible for websites to have a pleasant design without relying on images. Nevertheless, we can be assured that even today, there is some poor soul slaving over an image map configuration as you read this. Here’s to you, luckless web developer, we salute you!
If you happen to be interested in history like this, feel free to subscribe below.