Problems with reusing the map element

[zcorpan]

I see some problems with reusing the map element as currently specified:

• The model for client side image maps and web maps are fundamentally different.
  • For client side image maps, you can have multiple img elements refer to a single map element, and both images apply the map's areas. (Example.) The img is what renders the image, and the map only provides the link between the img and the areas. The areas are hyperlinks that can receive focus and clicks. The map itself has no special rendering.
  • For web maps, there is no img element, instead the map element is the "widget" that owns the rendering and interaction model with panning and zooming.
• The duality means that a map element needs to be able to "upgrade" to a web map. In https://github.com/Maps4HTML/MapML-Proposal/issues/17#issuecomment-645661963 @Malvoz thought this could be toggled by the presence of layer elements. This means extra implementation complexity:
  • UAs need to have a mutation observer for all map elements to watch for added and removed layer children, and be able to toggle the "web map" rendering on and off in response.
• map is, for better or worse, not getting much love from browser vendors. Although there were evidence that web developers wanted variable-size image maps in 2015, the only improvement since then has been alignment on coords parsing in the spec (implemented in 2 out of 3 browser engines).
• The web compat impact of making changes to the map element is unknown and needs research. map is used on 1.96% of the web (httparchive data).

Benefits to using map:

• the element name makes sense for the feature
• the client side image map feature could be considered to be a "simple map", so per Evolution not Revolution design principle it can make sense to extend client side image maps. However, I think the first 2 points above show that it's not an extension but opting in to a different model.

A new element name that doesn't show up in httparchive (check with https://rainy-periwinkle.glitch.me/ - via https://almanac.httparchive.org/en/2019/markup ) has these benefits:

• Close to zero web compat risk (so no in-depth web compat research needed)
• No "unnecessary" implementation complexity - the web map rendering would be "always on".

If you want to change the model to actually reuse map's existing model, you would extend img to support panning and zooming and so on, and keep map as a "provides data" element. But I haven't thought about the implications of that yet.

[prushforth]

I had thought that the future progressive behavior could be triggered by the presence of the lat, long and zoom attributes. Also, if those attributes were present, and an img associated via selection based on its usemap attribute, the IMG could be used as the first map layer i.e.pannable/zoom able

If a new element name is chosen, we will need to design how the new element behaves in, say ie 6, or any non conforming browser, since it will be likely that it takes time, perhaps years, to roll out across all browsers. That's one reason I imagined that IMG/MAP/ AREA could be useful, if we plan for them to provide a useful fallback. More later if I think of something.

[zcorpan]

I had thought that the future progressive behavior could be triggered by the presence of the lat, long and zoom attributes.

OK, attribute based switches are simpler than children-based switches, but is still more complex than an element that is "always on".

Also, if those attributes were present, and an img associated via selection based on its usemap attribute, the IMG could be used as the first map layer i.e.pannable/zoom able

How would that work? The img and the map would both show the same image? The processing seems to not be defined in the spec.

A new element behaves like span in current browsers. Like video, content could be placed in the element for providing something for browsers that don't support the new feature. Or it can be feature-checked in JS and be replaced with one of the existing map solutions.

I'm not sure img/map/area is really a useful fallback for web maps. I expect a JS-based web map to be used if the feature is not supported. But it would still be possible to use img/map/area as fallback of a new element.

[prushforth]

OK, attribute based switches are simpler than children-based switches, but is still more complex than an element that is "always on".

Understood. Not to give too little weight to implementer-borne complexity putting the whole project at risk, but should we look at this in terms of the priority of constituencies?

Also, if those attributes were present, and an img associated via selection based on its usemap attribute, the IMG could be used as the first map layer i.e.pannable/zoom able

How would that work? The img and the map would both show the same image? The processing seems to not be defined in the spec.

No, it's not defined yet. I experimented a little with it though: here's an example in which, IIRC, I immediately deleted or suppressed the img element, and turned the area elements into layers which are then available on the layer control.

It needs further thought, and experimentation, not to mention agreement, before specifying, but I think another approach might be to turn the set of img/area elements into a single composite layer that would pan/zoom +/- two or three zoom levels (by scaling the image and areas). The author could decide whether to add other layers in their script, based on feature detection.

Like video, content could be placed in the element for providing something for browsers that don't support the new feature.

Yes. I believe that when video was being developed, it was seeking to replace Flash objects, and the advice at that time, IIRC was to place a Flash player object in the element as a fallback. So, you still got a video, even if you had to rely on Flash to achieve it.

Or it can be feature-checked in JS and be replaced with one of the existing map solutions. I'm not sure img/map/area is really a useful fallback for web maps. I expect a JS-based web map to be used if the feature is not supported.

Yeah, I guess it could. This requires experimentation as well. You would not get the benefit of having a script-free map if you had to include the scripts for a mapping framework, not to mention you would have to know the framework pretty well to achieve it. I was hoping to achieve a Web platform-centric proposal.

But it would still be possible to use img/map/area as fallback of a new element.

Would be good but it's not responsive. Also, would have to delete/hide all that stuff either automatically (i.e. the browser would have to be involved, which to be fair I am proposing, but haven't worked out the details completely enough to specify) or with script, which doesn't seem to be too graceful.

[Malvoz]

I had thought that the future progressive behavior could be triggered by the presence of the lat, long and zoom attributes.

OK, attribute based switches are simpler than children-based switches, but is still more complex than an element that is "always on".

For non-geographic content it doesn't make sense to require most/all the aforementioned attributes, see https://github.com/Maps4HTML/HTML-Map-Element/issues/18#issuecomment-645993801.

[prushforth]

I had thought that the future progressive behavior could be triggered by the presence of the lat, long and zoom attributes.

OK, attribute based switches are simpler than children-based switches, but is still more complex than an element that is "always on".

For non-geographic content it doesn't make sense to require most/all the aforementioned attributes, see https://github.com/Maps4HTML/HTML-Map-Element/issues/18#issuecomment-645993801.

Unsure where to respond. For non-geographic content, we need to provide a standard coordinate system that works the same as the geographic coordinate systems, and probably one that is numerically identical to that called "WGS84" in the MapML proposal, but perhaps under another name - TBD. In any case, the starting conditions of a map in that coordinate system need a point to define the location of the centre of the map, as well as a zoom level. In a non-geographic CS, you would have to ensure that the tiles and zoom levels of content you create match the definition of this coordinate system, so that you would benefit from the responsive (pan/zoom) behaviour kicked off by the new element ([map/other] w lat/lon/zoom attributes). In either case (geographic or non-geographic), zoom is a common property of the map. Only the axis names are different from latitude/longitude. That might be a bit confusing for users, I agree, which might be reason enough to create a new alias for WGS84 with different axis names. But, the behaviour of a map would be the same.

To step back a bit, one of the major inhibitors of geospatial interoperability is lack of, or complexity involved in transforming among, common coordinate system definitions. MapML skirts this problem by providing the common coordinate system definitions within its definition, and by more or less suggesting that coordinate transformation of layer content from one TCRS to another is not recommended or desired; either provide content in the TCRS of the map, or resign to the fact that it can't be mashed up.

By "geospatial interoperability" I mean the ability to overlay, or mash up, layers from different sources so that they can be compared / visualized within a single coordinate space, on a map. I don't know how much of that consideration applies to non-geospatial maps, but the concept of layers of non-geospatial content is still potentially valuable, and common too, I believe.

In sum, you still need a map centre coordinate and a zoom level value to locate the map's starting condition, regardless of what you call the axes. lat/lon are common and potentially "good enough" as attributes of the (map) element YMMV.

[Malvoz]

Accessibility issue with polyfilling the map element: https://github.com/w3c/html-aam/issues/292.

[Malvoz]

Accessibility issue with polyfilling the map element: w3c/html-aam#292.

Another issue I came across, which may just be a result of NVDA following the rules in https://www.w3.org/TR/html-aria/#el-map, which is that role="application" (works well and is needed for multiple reasons on the <mapml-viewer> polyfill) is not applicable to <map> and so the interactive elements in the <map> polyfill aren't keyboard operable using a screen reader.