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

@js-choi :

> • 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.

> How is this relationship special, to warrant such privileging over alternative relationships? 

I don't think the relationship between bitmaps graphics and maps is special, just that the map element exists (was created at least partially to support [ geographic maps](https://weather.gc.ca/canada_e.html)) and has approximately the right "[semantics](https://tink.uk/understanding-semantics/)" as a basis for progressive enhancement.  Making that (geographic maps) the "special" enhancement path over alternative relationships really only changes future behaviour, not existing (at least that would be the goal).  Furthermore, as was pointed out earlier in this thread, the <map> element is essentially abandonware from a maintainer's viewpoint; **it needs a community**.

> a hypothetical native <geo> element (which I would love) would support fallback content, just like <video>, <audio>, <canvas&gt,

Picking one example, back in the day, the <video> tag needed Flash as a fallback, which then used <img> as a secondary fallback, I [believe](https://css-tricks.com/snippets/html/video-for-everybody-html5-video-with-flash-fallback/).  Interesting today though, since Flash is essentially dead, is there a fallback for browsers that don't support <video>?

I believe an author could use JavaScript maps as a fallback for <geo> or <map>, for that matter.  Probably that would be the way to go for a not-so-primitive user experience.  

> static images, and text are very generic solutions that trade native-system-like functionality for universality.

I'm convinced (I've convinced myself anyway) that even [the most sophisticated modern Web maps](https://www.google.ca/maps/) are but elaborations on the 'links displayed on top of bitmap graphics' theme.  So let's say that JavaScript failed to load, or as in my case, loaded but had several errors in it.  What would be the secondary fallback for <geo> ?  Perhaps an image, but if you were being kind to the [user](https://www.w3.org/TR/html-design-principles/#priority-of-constituencies) and not denying them the 'links displayed on top of bitmap graphics' experience, you would use an image map, I think, precisely because of its universality.

> custom elements fall back onto their content in browsers that do not support their special behavior.

Exactly, if we're nice to our users, we won't mess that up. Ideally the fallback needs to approximate the desired behaviour. Leaving scripted fallback aside for a moment, what content would you recommend to fallback to for a <geo-map> custom element?

>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.

I think this use case is in scope, although we haven't addressed it yet.  I know that Leaflet.js for example supports zoomable pannable [maps ](http://leafletjs.com/examples/crs-simple/crs-simple.html)and [images ](http://leafletjs.com/examples/extending/class-diagram.html)that aren't georeferenced.  I guess this is the "advanced image map" responsibility that would come with extending image maps.

> I am rooting for your community group

Thank you very much.  I am in awe of the Web platform standards.


-- 
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-366357589