Re: Image map resizing

The problem in the age of HTML4 could also be a poor implementation on the
UAs side. The fact is, everybody resorted to use animated Flash image maps
but nobody used native technology. Exactly what happened later for videos
and animations (features for which the new elements <video> and <canvas>
have been developed). And vendors have adapted.
What I ask for is a correction of an existing feature which would help a
lot for a number of reasons, also because the map itself does not need to
be next to the image and can be in any other part of the page itself.

Actually I had two different proposals, and I will write them here:

   1. Maps should present coordinates relative to the default image
   dimensions (i.e. according to @width and @height, or to dimensions fetched
   from the image file). Visual user agents dealing with <area> elements
   inside <map@resize> should store coordinates starting values, then apply
   CSS transformations, storing width and height stretch/shrink ratio, then
   apply these ratios respectively to horizontal and vertical coordinates, and
   after these passages areas should be rendered properly. In order not to
   break with existing projects where maps are made with reference to the
   final apperance of the image, <map> should have a new boolean attribute
   @resize. Only image maps with this attribute should be resized with native
   UAs techniques.

   This is a first scenario. Its major issue is that it could be
   incompatible with JS solutions used in legacy installments: if JS is
   completely discarded, then resize scripts are disabled. But scripts used
   for animating areas would be lost as well, because there's no way to tell
   them apart (I don't even know if anything similar exists).

   2. (secondary) IMHO this is a better idea but it requires some more
   guessing. Relative coordinates: numbers in the coords attributes could be
   expressed with percent values, so calculations would also be easier to
   achieve and more immediate to understand (it should be noted that this
   would require floating-point values in most cases, as integer numbers
   wouldn't be precise enough).

I don't know what HTML4 used to say about percentage coordinates. What I do
know is that modern user agents don't know what to do with percentage
coordinates. Chrome treats them as pixel and that's all. IE and FF (they
behave quite similarly in some case and this is weird) treat them as pixel
for "rect" state, while circles and polygons disappear (I guess).

2015-03-06 3:12 GMT+01:00 Boris Zbarsky <bzbarsky@mit.edu>:

> On 3/5/15 7:04 PM, Andrea Rendine wrote:
>
>> Coordinates in area elements are absolute
>> and refer to distances and measures in pixels
>>
>
> I believe in HTML 4 coordinates could be percentages and no one ever
> implemented that...  Would that help things somewhat?
>
>  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.
>>
>
> The element wasn't used much at all for many years before people worried
> about responsive design...  I've never quite understood why, since it _is_
> in fact pretty useful, but that's the way it was.
>
> -Boris
>
>
>