>> why not improving an existing feature
> See https://wiki.whatwg.org/wiki/FAQ#Where.27s_the_harm_in_adding.E2.80.94
Yes, I think I should have expressed it better. Why not improving *this*
specific feature?
I'm aware that older elements could end up being incompatible with use
cases they have served as of now.
That's why, instead of changing something, I guess it's better to *add*
something, so that legacy UAs keep on behaving as they can (and probably
rely on polyfill) while compliant browsers treat new features (elements,
attributes, etc.) properly.
You can see my original idea at the beginning of this thread. What I
proposed is to add an attribute to <map> element, let's say "viewbox" or
"sizes". This attribute shows the width and height (properly separated by
space or comma) for which <area>s coordinates are intended.
<map id="resizable" name="resizable" viewbox="640 480">
<area href="rectangle.html" type="rect" coords="0,0,320,120" />
Now, suppose this map is applied to an image resized to 800x720. <area>s
have to be resized as well, according to proper ratios.
So horizontal coordinates (odd positions in the coords list) are to be
stretched them by (800/640) = 1.25 times, while vertical coordinates (even
positions in the list) by (720/480) = 1.5 (just to handle cases where the
original image ratio is stretched). So the adjusted coordinates would be
(0*1.25,0*1.5,320*1.25,120*1.5) = (0,0,400,150).
As said, the only problem would be with circles which should be stretched
into ellipses when ratios are not equal.
 - resizing does not apply on old maps (without this attribute) and they
probably rely on resizing scripts.
 - maps provided with viewbox attribute are resized natively on compliant
 - there should be an associated property to be recognized, so that
polyfill support can be provided on new maps *only* in those browsers which
do not know how to handle @viewbox and the resizing mechanism.
I hope it can be done as easily as it can be described.

Reply via email to