It's 2020 and I'm using image maps

TL;DR image maps are still useful in 2020, but for annotation instead of navigation.

I started with a task: how to annotate an image while keeping the annotations from obstructing the image. Since we'll want to go with interactable regions for parts of the image, the problem boils down to marking those regions in the image. Surely there's no proper way to do this in HTML though, right?

A distant memory from the early 2000s of partially clickable images and image-driven navigation bars visited my mind, but I quickly dismissed it as obviously something you would not do in 2020. However, despite the SEO odds, an article about annotating with imagemaps from 2004 popped up as the first search result for "html image annotation".

Armed with a very relevant quote We've moved away from [imagemaps] to a certain extent these days (in 2004!!), the article goes on to demonstrate how even back then image maps were still relevant for at least for the author's annotation library purposes. Sixteen years later in this article, we're gonna agree with the presumption and reimplement our own imagemap-powered image annotations.

Let's begin with syntax. Is imagemap syntax syntactically beautiful? I neither agree nor disagree, but will instead let you be the judge by showing what a complete rectangle-powering imagemap looks like:

<map name="interface-map"> <area title="Top controls" shape="rect" coords="0,0,1024,84" nohref="nohref" alt="" /> <area title="Asset library" shape="rect" coords="0,80,284,349" nohref="nohref" alt="" /> <area title="Edit view" shape="rect" coords="280,80,744,349" nohref="nohref" alt="" /> <area title="Preview view and layer properties" shape="rect" coords="740,80,1024,349" nohref="nohref" alt="" /> <area title="Playback and timeline controls" shape="rect" coords="0,350,1024,419" nohref="nohref" alt="" /> <area title="Timeline controls" shape="rect" coords="0,420,1024,519" nohref="nohref" alt="" /> </map>

Of course, having evolved at least by some degree from the 2004 state of the art, we know hold the privilege of not being under the iron fist of W3C Markup validation service and needing all the attribute cruft that was necessary back then (also the HTML5 spec changed). Instead of having a nohref="nohref" attribute in our <area> tag, we can now just drop the href attribute altogether. Brilliant!

However, we're not saved from the elegance of the coords attribute. In modern CSS, attributes that take four coordinates to form a rectangular shape (most prominently margin and padding) the coordinates are described in the order top | right | bottom | left (here's hoping I'm not the only who keeps having to look this up). Instead, to declare an imagemap rectangle, you'll need left | top | right | bottom order.

To make matters even more exciting, the last two coordinates might not be what you'd expect; when absolutely positioning items in CSS, right and bottom indicate the distance from the right and bottom edges respectively. In image maps, this holds no water. Instead, both horizontal coordinates are counted from the left edge and vertical coordinates from the top edge.

To find the reasoning behind the different order, I tried looking into the first CSS specification drafts I could find and compare their date to the image map RFC. This CSS W3C draft from late 1995 specifies the same CSS coordinate order that is being used on web browsers today, and is earlier than the image map RFC from 1996 I see no obvious reason why image map implementation would use different ordering.

In any case, finding reasoning for what in hindsight now feels like inanity was of no use in my mission. Onwards!

Implementation was not very difficult. (a) Querying the page for existing images with the usemap attribute, (b) building absolutely (but relative to the image size, get it?) positioned overlay annotations, (c) making them show up on hover, and we've almost reimplemented the 2004 library! Oh wait, what about responsive design? We forgot the phones (d for damnit)!

With the systematic (and thankfully touch-device only) touchstart events, we we're able to conveniently add an extra class to all touched annotations. If you'd like to test out the results yourself, the image is available here.

What did we learn and benefit from all this? Other than the joy of essentially reimplementing legacy features, not much. However, if someone at Google's search engine ranking department finds their old copy of Dynamic HTML from 2002, we might just be seeing an image SEO bump for the fellow imagemap users. At least it was empirically discovered that links from image maps are followed, although the image itself is still treated as one and not cut to pieces. Will this actually happen (or will we at least get some exciting image stencil shape cutting action in Google images results), probably not.

Appendix: are we just anti-HTML5?

A new web developer in 2020 will not be learning about imagemaps in their studies of the internet, so is this just misusing legacy HTML3 features for no good reason? Well, not quite. As established, image maps remain in the HTML5 specification as a fully supported feature (with some modifications and restrictions), and even MDN makes no mention of the alleged obsoleteness of the feature. Sure, the API looks and feels a bit dated, with its coordinates differing from the CSS standard and reliance on the name attribute, but on the other hand the modern hivemind seems to be heading towards semantic HTML elements. Image map with its privileged <map> and <area> tags is not a bad example of that.

However, for their intended purposes the time of imagemaps might just be over. For instance, resizing an image breaks the imagemaps since they rely on fixed absolute coordinates that do not scale with the image, and the HTML5 spec even removed the ability to specify coordinates as percentages. However, we'll be revisiting this opinion once responsive websites with their (gasp) automatically resizing images are out of fashion.