Questions about `<area>`

[Malvoz]

The proposed extensions to the shape attribute were removed in https://github.com/Maps4HTML/MapML/pull/187, does that mean the following statement is incorrect:

The intention of the area element is to extend the behavior of the existing [HTML] area element.

or is the element's behavior extended in other ways?

---

Is <area> only intended to be used as a fallback for browsers that do not support MapML? (graceful degradation of <map>)

(Either way, we should probably have an example of <area> usage in the authoring examples).

---

Do we still care about responsive image maps? (https://github.com/Maps4HTML/MapML/issues/101)

[prushforth]

I think that area is extended in that it creates a "layer" of a single feature using map coordinates, but the only time you would use it would be where you wanted a fallback. In other words, if area is present, it represents a link, whether the map is progressed or not.

So if the map is progressed, the area would be responsive, because it would act like a layer with just that one feature in it. I'm not sure we'll be able to convince anybody to make the non-progressed areas responsive but that would be better IMO than preventing CSS from affecting coords as is the case now I think.

[Malvoz]

I had forgotten that this was also answered in the MapML Proposal:

If <area> elements are present (for fallback) as child elements of <map>, they are (progressively, if the conditions warrant) treated as <layer> elements containing a single geographic feature, with coordinates in the coords attribute being interpreted as being valid pixel coordinates in the map’s locally defined map coordinate system. More detail and a working example of how graceful degradation and progressive enhancement could work in this proposal is available.

It seems a bit problematic that <area> is supposed to be active in both scenarios, because it means that the author must use feature detection to remove/hide any <area> elements in case they only want to use them as fallbacks (in which case non-responsive <area> wont fulfill their needs as "all" web pages today are responsive).

[prushforth]

It seems a bit problematic that <area> is supposed to be active in both scenarios, because it means that the author must use feature detection to remove/hide any <area> elements in case they only want to use them as fallbacks

This is a complex area (for me at least), because it involves figuring out what scenarios apply and how the author got into them etc. But I think that <area> would be a legit layer, so if you wanted a declarative fallback (not every map will (need to) care about this, I hope/pray), then the map itself would have to be pretty simple (simple purpose), like this one, possibly. When not relying on declarative image map behaviour, I think a more likely scenario is JavaScript mapping library fallback, i.e. fall back to Leaflet etc.

"all" web pages today are responsive).

I don't understand this; but besides maybe it will be possible to improve the situation with responsiveness of <area coords> one day, if the <map> element does end up being maintained properly.