W3C home > Mailing lists > Public > public-html@w3.org > March 2015

Image map resizing

From: Andrea Rendine <master.skywalker.88@gmail.com>
Date: Fri, 6 Mar 2015 01:04:00 +0100
Message-ID: <CAGxST9=DQXBPC=W8hk=snBSzmj8MZ4s2WqTvfBYQzVgrBL10fQ@mail.gmail.com>
To: public-html@w3.org
Greetings to everybody.
Recently I noticed how much work is needed in order to put navigation
commands in images. This is usually achieved through a transparent layer
with commands "covering" the images.
I know that there is an element I could have used in order to put simple
command on parts of the image: client-side image maps (

But several modern solutions choose to use HTML overlay elements, because
of a simple yet vital problem: *image maps aren't responsive*.

*For historical reasons, the coordinates must be interpreted relative to
the displayed image after any stretching caused by the CSS 'width' and
'height' properties (or, for non-CSS browsers, the image element's width
and height attributes — CSS browsers map those attributes to the
aforementioned CSS properties).*

*NOTE: Browser zoom features and transforms applied using CSS or SVG do not
affect the coordinates.*

This isn't something I can accept easily. HTML today can natively serve
advanced embedded content; on the other hand, CSS resizing/transformations
are the best choice for presentational solutions and responsive/resizable
content. But everything collides with this sort of jurassic oddity.
Coordinates in area elements are absolute and refer to distances and
measures in pixels, computed on the image after resizing (but actually
resize plays no role on them). What if the image is adapted to viewport,
zoomed or resized?

It can't be a matter of lacking interest on the part of authors and/or
vendors: if the element is not usable as it is *today*, then of course
nobody can effectively use it and vendors don't guess too much about an
unused feature. It ends up being a vicious circle. And I'm sure that
vendors had no interest in other features before anybody started to develop
custom alternatives, such as datetime input or advanced interactive
embedded content.

And no, actually I'm not the only one with this issue. Otherwise the
solutions as the ones I will present below wouldn't have been even
conceived (these are just examples):
This is not just me becoming mad for marginal stuff. So I came up with some
ideas. But before this message becomes too long, please give me some hints
about how this could be done or why it shouldn't be done.

Received on Friday, 6 March 2015 00:04:28 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:42 UTC