Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Questions about <area> #191

Open
Malvoz opened this issue Jun 19, 2021 · 3 comments
Open

Questions about <area> #191

Malvoz opened this issue Jun 19, 2021 · 3 comments
Labels

Comments

@Malvoz
Copy link
Member

Malvoz commented Jun 19, 2021

The proposed extensions to the shape attribute were removed in #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? (#101)

@prushforth
Copy link
Member

prushforth commented Jun 19, 2021

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
Copy link
Member Author

Malvoz commented Jun 23, 2021

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants