Progressive Web Maps
There is a lot of discussion about things 'progressive' these days. The competition between the Web Platform and the mobile native platforms is heating up. It is not overloading the term to point out the connection between 'progressive' behaviour and extending the Web platform, which is the broader subject category of this post about Web mapping.
The narrower topic here is: should we (the Maps for HTML Community Group) create and eventually propose a new element for HTML which has map semantics but is called something else, for example "webmap", or should we create and propose extended image map behaviour for the existing HTML "map" element.
The currently accepted best way to influence the Web Platform (i.e. the set of browsers whose developer teams support the WHATWG / W3C processes) is to: a) have a community and b) build a prototype if possible that demonstrates the idea and c) come prepared.
Relative to a), we warmly invite you to join our CG to show your support, or even contribute 😍.
In order to address b), evolving modern Web standards in the form of Custom Elements give us the opportunity to simulate how a proposed "native" Web platform element might behave, and that fact is long overdue, perhaps explaining why maps are not yet part of the Web platform.
There are two options for new behaviour in declarative HTML: extending the semantics of existing standard markup by with attributes and/or permitted content or defining entirely new elements. Although the barrier to doing the latter might seem lower at first glance, there is a school of thought which suggests that the former approach provides better value to the Web platform.
Custom Elements supports both paths. There are two types: autonomous custom elements with a hyphen in the name e.g. <taco-button>Eat me!</taco-button>, and customized built-in elements, which override the behavior of an existing HTML element by adding the "is" attribute e.g. <button is="tequila-button">Drink me!</button>.
Show Me The Map!
<-- You will see the old image map behaviour if: -->
<-- * you're using an IE browser, this page should force IE7 mode -->
<-- * in FireFox, if Web Components are enabled, I believe the HTML import for the map custom element won't work -->
<-- * in any browser if you disable javascript -->
<-- else the map@is=web-map should have custom behaviour, including zoom, pan, layers, controls etc. -->
<-- The img element is only used for fallback processing, otherwise it is deleted by the custom element on load -->
<img usemap="#dowslake" src="map1.png" width="700" height="400" alt="Dow's Lake area" />
<-- The map element can be set up by the HTML author to provide the old image map behaviour -->
<map name="dowslake" is="web-map" zoom="17" lat="45.398043" lon="-75.70683" width="700" height="400" controls hidden>
<layer- id="osm" src="http://geogratis.gc.ca/mapml/osm/" label="Open Street Map" checked hidden></layer->
<layer- id="canvec" src="http://geogratis.gc.ca/mapml/canvec/50k/features/" label="CanVec+ 031G" class="transparency"></layer->
<layer- id="marker" label="Marker layer" src="marker.mapml"></layer->
<area is="map-area"id="marker2" href='http://example.com/marker/' alt="Marker" coords="265,185" shape="marker">
The shape=marker keyword is new, if we want a link there in old UAs we have to provide a fallback, using rect
<area is="map-area" href='http://example.com/marker/' alt="Marker" coords="255,145,275,190" shape="rect" style="fill: none">
<area is="map-area"id="line" href='http://example.com/line/' alt="Line" coords="275,275,540,107" shape="line">
<area is="map-area"id="donut" alt="Circle" href='http://example.com/circle/' coords="250,250,25" shape="circle" style="fill: white; stroke: aqua; stroke-width: 5px;fill-opacity: 0.0">
<area is="map-area"id="hole" coords="250,250,7" shape="circle" style="fill: blue; stroke: none;fill-opacity: 0.3;">
<area is="map-area"id="rect" href='http://example.com/rectangle/' alt="Rectangle" coords="345,290,415,320" shape="rect" style="fill: greenyellow; stroke: blue; stroke-width: 3px;fill-opacity: 0.4">
<area is="map-area"id="poly" href='http://example.com/polygon/' alt="Polygon" coords="392,116,430,100,441,128,405,145" shape="poly" style="fill: pink; stroke: blue; stroke-width: 3px;fill-opacity: 0.4">
</map>

Here it is. You can refer to that page as you read along, possibly loading it in different browsers, or reloading without JavaScript etc., to get the idea of what is being discussed.
There are many considerations to both avenues, and we are seeking feedback with this post about what is the best route for web maps. We are not yet at the proposal stage, but we will get there eventually. Your feedback now would be greatly appreciated.
Progressive Enhancement and Progressive Web Apps
At its core, a Progressive Web App is one that (among other important characteristics) uses progressive enhancement as a means to support offline behaviour with or possibly even without service workers (because there are varying degrees of offline – some domains may be dead while others are available) (The truth is that I have not had the time to learn about and implement a Service Worker feature for the above page, but I'm pretty sure that it will already enhance progressively with varying degrees of browser technology and connectivity. If anyone is interested enough to try to implement a SW for that page, that would be very cool, get in touch!).
An important question a new element design has to consider is: "What will user agents that don't support or know about this element do when they encounter it"? I.e. what is the fallback strategy for the element in a user agent that doesn't know about it.
For a new native unknown or 'autonomous' custom element, the answer is that nothing will happen, and the experience the user has will not likely be the desired one. The user agent will parse the document and find unknown HTML elements, which render their text content, if any. Possibly script could be used for damage control, or noscript used to suggest upgrading your browser (graceful degradation).
For a 'built-in custom' or an extended existing native element, the situation can be simulated today by running the page in an Internet Explorer, which doesn't support Web Components. If the fallback strategy in the latter (native extended element semantics) case relies on providing a (Custom Element) shim or polyfill, what will the browser do with script turned off/or script errors? Shutting script off in any browser would seem to simulate the script-turned-off situation today. However, probably more common will be the script-errors case, especially my own!
Semantics
Although cartographic applications are not currently reflected in the HTML map element specification examples, they are definitely part of the heritage and meaning of the element. According to Dan Connolly, the original (server side) image maps (img@ismap) began partly in support of the original web maps developed by Xerox PARC. Their subsequent evolution to img@usemap not only solved the problems with server side image maps, it provided a progressive enhancement-type path for HTML authors, by design.
The HTML map element described by that RFC does essentially what a (primitive) web map should do: portray a two dimensional space and allow the HTML author to create shaped links in that space. In other words, it already has the core semantics we need for Web maps. Clearly it's not responsive, and it lacks more advanced Web mapping features or behaviour, but it is the kernel of the user experience that one wants with a Web map. Consider Google Maps, for example. Apart and aside from the incredible and evolving user experience, what is it? Essentially, it is a two dimensional picture with hyperlinks on it.
According to the latest draft of the Custom Elements spec:
"…user agents and other software key off an element's local name in order to identify the element's semantics and behaviour. That is, the concept of customized built-in elements building on top of existing behaviour depends crucially on the extended elements retaining their original local name."
A key question you may have is: "What new behaviour should the new map element have?" There are documents about the use cases that should be supported, and I think they are relevant here. Please, have a glance at them. Although development is not complete at the time of writing, some key use cases across the different categories of User Experience, HTML Authoring and Map Content Authoring are supported by the evolving prototype.
Knowing what the thing is supposed to do may lead to another question: "Is there a good place to start / extend from which already exists in HTML, and could there be an organic extension of that to support these use cases without disrupting existing applications?
This is the advice of Custom Elements' (earlier) designers:
The simplest and most robust method to create custom elements that are usable and accessible is to implement custom elements as type extensions. This method provides a custom element with built in semantics and interaction behaviours that developers can use as a foundation.
The reason they give that advice is because of the default semantics of autonomous vs customized built-in elements .
Accessibility
One of the main reasons you should favour extending an existing element when creating custom elements is because (in theory, at least) you get accessibility already baked into the element, based on what you're extending. Bruce Lawson perfectly described the reasoning behind this, way ahead of the curve (as usual).
Then again, Bruce's examples are based on "super-whizzo-fabbo-megalicious UltraShiny" Web Component checkboxes, and here we're talking about plain old semantic HTML image maps, not a user interface thingy.
Steve Faulkner described the accessibility of built in HTML elements, and why you should increasingly rely on them. I'm not certain how much this applies to the map element, as it has no default role and a 'transparent' content model in HTML5 – perhaps it applies more so to the child element - but it is obvious that progressive Web maps must be accessible, continuing and possibly extending the existing accessible features-as-hyperlinks (<area>) model that can be tabbed to and manipulated with Assistive Technology. Some applications of today's HTML map element are designed for accessible cartographic maps that eschew script. With your input, we can define the appropriate baseline for accessible Web maps for the platform.
Conclusion
The intended semantics and behaviour of the map custom type extension element continues evolution of Web (platform) maps, albeit 20 years after the last step. We had to wait for Custom Elements, to come along to make this path possible.
The map element has apparently been a little bit neglected by the standards maintainers, no insult intended, perhaps because there are alternative, modern techniques to accomplish the site navigation use cases which seem to have become prominent in the standards developers' minds. But more likely, it is because the attention and support of the Web mapping / geospatial / open data community who might benefit the most from a more functional HTML map element, has been long diverted – once again possibly waiting for Custom Elements to herald a new era in platform evolution.
This is a perfect opportunity to give the map element, and by extension the Web platform itself, continued relevance. Nothing could be better than to initiate and stoke a virtuous feedback cycle https://extensiblewebmanifesto.org/ between the geospatial and Web developer communities at a time when the Web in crisis https://medium.com/@stopsatgreen/the-crisis-facing-the-web-platform-4ab47515ed42#.b9g8ecm28 and geospatial technology is fast receding as a distinct discipline unto itself https://www.google.ca/trends/explore#q=geographic%20information%20systems .
Let the Web mapping community have the map element and together let's take on the challenge of the mobile platforms, aided by Progressive Web Maps. And by "let", I mean help us identify and test all the details that will make the addition of Progressive Web Maps (PWA) a progression in the Web platform itself.