Image Maps: A Trip Back to the '90s
When designing a new site for Emmy-winning game composer Mike Worth, the goal was ambitious: capture the bold, graphical spirit of '90s web design while building with modern, accessible, and responsive code. Worth loves that era's animation—think Duck Tales—and the challenge was to channel that energy without turning the site into a pastiche.
Looking back at what made that period distinctive, many early sites used graphics to fuse branding, content, and navigation into a single visual unit. Sites for brands like Nintendo and properties like Goosebumps were playful and visually rich, yet they remained fully functional. They were useful without being boring.
Back then, building those graphics meant slicing images into tables or using image maps. Image maps are still with us, and they're worth a fresh look.
The Basics of Image Maps
Image maps date back to HTML 3.2. They made images clickable by defining hot regions using <map> and <area> elements. The map is connected to an image through the usemap attribute:
<img usemap="#projects" ...>The <area> elements can each have their own href and alt attributes, and can be made more accessible by adding ARIA properties:
<map name="projects">
<area href="" alt="" … />
...
</map>The required shape attribute defines the region as either a circle, a rect, or a poly (polygon). For the latter, x and y coordinates are given as a list of absolute positions:
<area shape="circle" coords="..." ... />
<area shape="rect" coords="..." ... />
<area shape="poly" coords="..." ... />Despite their age, image maps are light and require almost no JavaScript. They're semantic and, when used with alt text, title, and ARIA, they can be quite accessible. All modern mobile browsers support them.
When Flexible Images Meet Fixed Coordinates
For Mike's site, the concept was an explorable map with numbered circles. Pressing one opens a modal about a specific piece of work. Initially, the project seemed like a perfect candidate for image maps.
Embedding anchors in an external SVG was a first thought, since those SVG anchors could be linked from the site. But that fails: external SVG anchors don't work when the SVG is referenced via an <img> element, only when it's inline. Image maps don't have that limitation, so they looked like the pragmatic choice.
Generating coordinates is the tedious part, but standalone tools take care of mapping shapes, letting you draw over an image and copy the resulting markup. Still, that solves the creation problem, not the responsiveness problem. Image map coordinates are absolute pixel positions. When images reflow or scale responsively, map regions do not.
Making an image map responsive requires JavaScript. The script recalculates area coordinates on load and whenever the image's rendered size changes:
function resizeMap() {
const image = document.getElementById("projects");
const map = document.querySelector("map[name='projects-map']");
if (!image || !map || !image.naturalWidth) return;
const scale = image.clientWidth / image.naturalWidth;
map.querySelectorAll("area").forEach(area => {
if (!area.dataset.originalCoords) {
area.dataset.originalCoords = area.getAttribute("coords");
}
const scaledCoords = area.dataset.originalCoords
.split(",")
.map(coord => Math.round(coord * scale))
.join(",");
area.setAttribute("coords", scaledCoords);
});
}
["load", "resize"].forEach(event =>
window.addEventListener(event, resizeMap)
);Even with the responsiveness sorted, there was another limitation: the image map gives clickable areas only as precise as the original coordinates. They can't easily match irregularly shaped paths, like the regions used for a creative design.
Paths, Points, and Conversions
Another route uses SVG <path> elements. A path's coordinates are relative to the SVG's viewBox, but an <area>'s coordinates are relative to the top-left corner of the image. To convert between them, a tool like PathToPoints helps. Given an SVG, it extracts coordinates into a format that can be dropped into an area's coords attribute:
<map>
<area href="" shape="poly" coords="...">
<area href="" shape="poly" coords="...">
<area href="" shape="poly" coords="...">
...
</map>An SVG Alternative
Image maps have other quirks. They lack visible states; hovering or clicking gives no feedback beyond the cursor change, and adding animation or interactive effects isn't straightforward. Their pixel-based nature makes maintaining them hard when layouts change—plus defining areas is tedious without generation tools.
The answer for this project was inline SVG. Instead of a raster image with clickable regions, the whole map is built with vector shapes. The process is simple:
- Create an SVG path for each clickable area.
- Add the invisible paths over the visual ones.
- Nest the invisible paths inside anchors.
- Place the anchors at the end of the SVG's source.
- Use the SVG inline, not as an external file.
What does that buy? The map's paths can be much larger than the numbered circles, creating inviting targets that don't require precision. And because the anchors contain real SVG elements, they can respond to user actions. Reduce their opacity to 0 and add a transition, so on hover they visually acknowledge the user's action:
#links a {
opacity: 0;
transition: all .25s ease-in-out;
}
#links a:hover {
opacity: 1;
}Unlike image map hot spots, embedded anchors give browsers and assistive tech a real interactive element to work with. They also provide a surface for richer interaction—adding a gloss effect to match the site branding, or content like a title or image preview that foreshadows the modal that's about to open.
<g id="links">
<a href="…">
<path fill="#B48F4C" d="..."/>
<image href="..." ... />
</a>
</g>Historical Tool, Modern Result
Image maps proved to be the perfect thing to revisit for this project. They gave the map another shot, surfaced its limitations, and pointed toward using modern HTML and SVG techniques to get a more expressive yet fully semantic and responsive result.
The big takeaway: choosing the right tool sometimes means looking backward. Image maps aren't inherently bad, but for a graphical, interactivity-focused site they have a more natural successor in inline SVG.
