Webcomponents: Please add <map> to the list of elements that support attachShadow(init)

[prushforth]

When appropriate, would you please consider adding the <map> element to the whitelist of elements which support a shadow root: https://dom.spec.whatwg.org/#dom-element-attachshadow

<map> is very useful to my project and it would be ideal if we could use it as the basis of a custom element. Thanks for considering this.

[domenic]

I don't think this will be possible, as image maps are quite complex and giving them a shadow root would cause strange interference with their function as image maps and their connection to area elements.

[prushforth]

I thought that because it has a transparent content model it might be straightforward, rather like a span. I have created a custom element that progressively enhances from an image map, and it works quite well, AFAICT. Was hoping that this could be a path forward. Perhaps not.

[annevk]

I think as long as we don't look into the shadow tree for any area elements it should be fine, but it does seem a little weird as the element is generally abandonware as far as implementation investment goes.

[prushforth]

Yes, that is very true, although there was some work done last year or so on web platform tests, by Travis Leithead, I believe. Anyway, we are trying in building a community to change the status as abandonware. Having a custom element that we can work with would be a great start for our community. And having the ability to stash the inner workings of that element in shadow DOM would be important, I think.

[domenic]

From what I can tell that community group is about geographic maps, not image maps. If that's the case I would strongly, strongly suggest not using the <map> element, but instead creating your own custom element.

It's unfortunate that sometimes we reuse an English word for different purposes, but I don't think you should make API decisions based on such word-reuse.

[prushforth]

@domenic I thought that was why customised built-in elements exist (conceptually anyway) - so that we could progressively enhance them?

[domenic]

Progressive enhancement doesn't mean reusing the same name for something totally different.

[bkardell]

I think @prushforth is making the case (could still be a bad case, just trying to help him clarify in case it helps since I've had a number of conversations with him around these same lines) that the map/area relationship is actually precisely what he is interested in, just more. He makes the case that it is an 'extension' of the existing map. At least this is my understanding and it does seem different from just overloading use of the convenient word 'map' if you accept the premise. Again, I'm not sure I do entirely, but it's interesting to think about in those terms.

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

I appreciate there are a whole host of technical and non-technical issues surrounding extending a long standing API.

I guess this is a conversation that must be had and it's not meant to be bikeshedding. It's meant to be practical, in fact.

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? 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. So, why not just extend the <map> element in the first place?

On the bikesheddy side, having two elements to do variations on one job is probably not great from a marketing POV - people might see the image map documentation and decide to go a complete other route, maybe even non-Web.

[domenic]

I guess I find it hard to understand why someone would think of an "old-school image map" as a reasonable fallback for a geographical map. They seem totally disconnected, apart from both having the word "map" in their name. The defining features of a geographical map are not related to shape-based hyperlinking within a raster image.

But If your community thinks that those two concepts are connected enough that one can serve as a fallback for the other, then I guess that's fine?

[js-choi]

@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. You posit the existence of a uniquely fundamental relationship 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.

But I am puzzled: How is this relationship special, to warrant such privileging over alternative relationships? Are images and cartographic maps of regions of Earth somehow intrinsically or practically 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 , , 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.

[prushforth]

@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) and has approximately the right "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. 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 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 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 and images 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.

[annevk]

I'm marking this as a duplicate of #511 as this was already requested there. I don't think we need to track the request twice in this repository. I also opened an upstream issue against whatwg/dom.

[prushforth]

@annevk Cool, thanks.

I'll just add a question here. If, in the future, the platform decided that it needed to use a shadow root on a native element that has allowed attachShadow() (i.e. its on the safe list), would that make it impossible for the platform to use the shadow root on that element? For instance, I believe the video element owns a shadow root, so it is not on the safe list, and so the platform 'own's the shadow root. If you decide to add (any) element to the safe list, does that mean in effect that the native element can never have a 'platform'-owned shadow root?

[annevk]

That's correct. We couldn't use map for another purpose at that point.

[prushforth]

Hmm, maybe I should reconsider this request then. Depending on if you think my arguments for extending <map> are significant?

[annevk]

I suspect that if we ever introduced a native way to embed a geographic map we wouldn't reuse this element.

[prushforth]

OK, well just in case I think I should withdraw this request. I'll re-write the custom element as autonomous.
Thanks and sorry for the trouble.