The area element

If you’ve never killed a Tamagotchi, you’ve probably never used an <area> element. Like Tamagotchis, <area> elements used to be all the rage, fell out of favor, and obstinately continue to exist.

The last time I wielded an <area> element, four things were very different:

  1. Nobody browsed the web on their phone.
  2. Nobody had the job title front-end developer.
  3. Nobody had the job title frontend developer either.
  4. Nobody had bought a yellow LIVESTRONG wristband from Lance Armstrong then later found it in the back of a sock drawer and made a disconcerted “oof” sound.

In the early 2000s, it would be difficult to overstate just how much designing for the web meant designing for print media then sticking it in a web page at the last minute. And that’s not because browsers were only capable of handling static, fixed designs at the time. In fact, they were designed for anything but. It’s just that print designers gonna print design and web design was yet to become its own thing. In many ways, we’ve still not got there.

When I started designing web pages professionally (read: making pictures of web pages in Photoshop and handing them to a programmer), every design was 800x600 pixels. Why? Because it was assumed most people had a monitor at least 800 pixels wide and 600 pixels high.

If you didn’t want anyone to see your design cropped off down the right hand side of a 640x480 monitor, you had to draw a salt circle, summon a minor demon, and give them €30 (Hell joined the Euro at the turn of the century, shortly after The Netherlands). Those few millionaires with 1024x768 monitors saw your design surrounded by a moat of white space.

If you didn’t know any programmers or they were all in their headphones, listening to Sabaton or some s**t, you had to fire up some software like Macromedia Dreamweaver™️. To say laying out web pages in (at least the early versions of) Dreamweaver was precarious would be an egregious understatement. There were a couple of approaches:

  1. Misusing data tables (<table> and friends) to create faux grids, putting words and text in the cells.
  2. Embedding the whole design as a single image and creating clickable areas with the <map> and <area> elements.

The <table> approach was a road to perdition. You’d spend hours dragging cell walls hither and thither only to open your design in a browser and discover they had *mysteriously shifted.

(*Not-so-mysteriously settled in places to which Dreamweaver’s graphical interface was not aware they’d be attracted.)

Working with image maps (<map> and <area>) was a lot more dependable. Dreamweaver’s UI for drawing areas (polygonal clickable shapes) onto the image was pretty usable, plus the polygon coords didn’t tend to go walkabout when you fired up a browser.

<map name="mySite">
  <area
    shape="poly"
    coords="48,249,0,96,129,138"
    href="https://heydonworks.com/about"
    alt="About my site" />
    <area
    shape="poly"
    coords="68,259,10,106,139,148"
    href="https://heydonworks.com/contact"
    alt="Contact me" />
</map>
<img usemap="#mySite" src="/path/to/homepage.jpg" alt="Welcome to my site" />

And this approach had other benefits.

It was a time when even basic design capabilities like border-radius didn’t exist. No such thing as web fonts either! No matter: you could make the “web page” in Photoshop (or Corel PhotoPaint; other misappropriated photo editing packages were available) using whatever fonts and curvy corners you wanted.

Then you’d just plonk it in an HTML document and superimpose some invisible clickable bits. It was kind of cool those clickable bits didn’t have to be box-shaped too. Achieving that by other means is quite a challenge, even now.

Of course, it was far from perfect. The image would have to be pretty large—and at a time when download speeds were slower. No text is selectable and the document structure to assistive technologies like screen readers amounts to an image with some links next to it. Oh and coords have to be in pixels so, if the image appears in anything but its natural size, all the areas go bang out of whack. This is probably why Google Maps does not use <map>. For their maps.

Despite all of this, it was still better than building your designs with <table>s and that’s my final word.


Not everyone is a fan of my writing. But if you found this article at all entertaining or edifying, I do accept tips. I also have a clothing line: