Re: [w3c/webcomponents] Please add <map> to the list of elements that support attachShadow(init) (#734)

> @prushforth: That post tries to illustrate that an image map is a primitive kind of web map. Links (area tags) are a primitive kind of geographic feature and images are content in (essentially) non-responsive web maps.

As a developer who would find access to system-native physical-map UI useful in web content, I am sympathetic with any effort to standardize it for the web platform. I applaud your stoking the activity of any community with such aims.

However, I too find this approach to couple images to physical Earth maps quite confusing. This close relationship surmised to exist between:

* Raster bitmap images in general (which include photographs, diagrams, art, and any other visual media).
* And cartographic maps showing a physical region of a projection of the planet Earth.

I am curious: How is this relationship special? Is this relationship somehow fundamentally closer than the relationship between a raster image and a 3D scene, or a video, plain-text representation, vector diagram, medical imaging, or anything else representable by a raster image?

> Let's just say you (the platform stalwarts) decide it's a good idea to extend and add maps. The adoption will not be even across all browsers at the outset, like any feature. So authors will need a way to backfill the browsers that haven't implemented. If it's an entirely new element, say <geomap>, , what would an author do for those browsers that don't support? 

I would imagine that a hypothetical native `<geo>` element (which I would love) would support fallback content, just like `<video>`, `<audio>`, `<canvas>`, and custom elements fall back onto their content in browsers that do not support their special behavior.

> They would likely want to put an old-school image map where the new map will be in other browsers, providing a primitive map-like behaviour on non-compliant browsers, I think. 

I would think it more likely that a content creator would attempt to use a `<canvas>`-using solution as fallback. That fallback in turn might theoretically fall back to static images (or even text) for last-ditch support without JavaScript. `<canvas>`, static images, and text are very generic solutions that trade native-system-like functionality for universality. This genericity makes them quite different in nature than a hypothetical system-native `<map>` element, and none of them are fundamentally coupled to cartography. And image maps themselves are very old technology, probably having dramatic impedance mismatches with any specialized function of raster images.

As an aside, it would be nice to be able to have native support for zooming and panning image content in general. But I would not think that such functionality would be intrinsic to maps of cartographic projections of planet Earth.

Having said all that, I am rooting for your community group. I hope a `<geo>` element might someday come paving the cowpaths of many cartographic custom elements.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/734#issuecomment-366342702