Re: [whatwg] Responsive image maps

That's exactly what I had in mind. I worked for a similar solution (now
sadly aborted). It implemented a world map with selectable countries
instead of free text fields / dropdown list. I had to use Flash because
image maps cannot be resized.
I like the idea of using both width and height for consistency, but I am
worried about what could happen when either attribute is specified. Of
course it would be equally needed to state what is the meaning of a "sizes"
attribute without separator (it could mean that the base map is to be
intended as a square, maybe). I took the idea of x meaning "times" from the
current  spec about @srcset, where "#x" refers to CSS pixel density.
And as an evidence that someone needs this feature, I could cite several
resizing scripts, both standalone
https://github.com/davidjbradshaw/image-map-resizer
http://stackoverflow.com/a/14576104
and jQuery-based
https://github.com/stowball/jQuery-rwdImageMaps

2015-03-18 16:50 GMT+01:00 Martin Janecke <whatwg.org@prlbr.com>:

> Am .03.2015, 12:38 Uhr, schrieb Andrea Rendine
> <master.skywalker.88@gmail.com>:
>
>  […] why can't map area coordinates
>> be responsive? I know that percentages simply don't work as UAs either
>> interpret them as pixel, or they aren't interpreted at all. But what about
>> rescaling?
>>
>
> I'd like to interpret this question as a request and support it.
>
>
>  Imagine something like this (it's a simple example with also an idea for
>> legacy compatibility):
>> <map id="mapname" name="mapname" sizes="400x300">
>> <area type="circle" coords="50,60,40" />
>> <area type="rect" coords="0,200,400,300" />
>> </map>
>> The @sizes attribute indicates the base dimensions for map rescaling.
>> Lacking it, the map is not resized (so to preserve legacy maps. "Polyfill"
>> resizing scripts could detect UAs which implement it and let them do it
>> automatically).
>> When the map is applied to an image, 2 values "horizontal_ratio"
>> (CSS-img-width / map-width) and "vertical_ratio" (CSS-img-height /
>> map-height) are calculated (I guess they should be 2 because CSS can be
>> improperly used to "stretch" the image). Then coordinates can then be
>> adjusted according to proper (hor/ver) ratio.
>>
>
> This sounds like an easy solution. I'd just suggest to consider whether
> the @sizes attribute could be expressed differently, i.e. without a new
> syntax like the "x" for "times". For example, the img element uses two
> attributes @width and @height to express something similar. Following
> that example might lead to a more consistent result.
>
>
>  I know that a major objection could be that <map> elements have been out
>> of
>> favor even before "responsive" design became a focus, but I think it
>> depends on the lack of any relationshipt between maps and rendering layer.
>>
>
> Image maps are still used even in a responsive environment. Here's an
> example from the wild:
>
> https://www.deutscheskonto.org/en/
> The image using the map is
> https://www.deutscheskonto.org/images/en/deutsches-konto-600-en.jpg
> This example uses JavaScript to make the map responsive, but doesn't work
> when the client has JavaScript disabled.
>
> While JavaScript could be used to solve the use case, making image maps
> responsive is such an obvious application that it makes sense to
> standardize it without JavaScript. It seems to be the natural evolution of
> image maps in a time of vastly varying screen sizes. Non-responsive image
> maps get less and less useful, actually.
>
> Martin
>

Received on Wednesday, 18 March 2015 16:23:15 UTC