Progressive Web Maps

Progressive Enhancement is at the heart of the Web. The Maps for HTML Community Group is making PE work for maps.

Progressive Enhancement

Progressive enhancement is a well-established practice. The core idea behind it is layering: markup delivers the essential content, with behaviour built into the browser; stylesheets provide adaptability to individuals and devices, and script delivers the finally enhanced experience if all goes well.

The layering principles behind progressive enhancement have spawned the notion of a Progressive Web App, in which certain features of mobile apps are layered on top of the essential user experience, to those browsers which support the advanced features. Notably, script can be used to progressively enhance the network itself, and provide an offline experience if necessary.

Similarly, progressive enhancement can also apply to the Web author experience. HTML authors don’t start out as CSS gurus, nor as fully-fledged framework programmers. We usually begin either as kids with a grade school homework assignment on how to create a Web page, or as curious adults who accidentally right-click on the View Source menu. Either way, the experience of going from being a Web user to a Web author can be seen in the light of progressive enhancement: understanding what HTML elements do and how to use them, followed by understanding how they can be laid out and perhaps, if you become a programmer, enabling more sophisticated interactions with scripting.

Image credit: Wikipedia

Progressive Web Maps

So, how does all this relate to Web maps? On today’s Web, there is a major disconnect between the map experience that most or all of us are familiar with and the sketchy foothold that the Web platform offers to maps as a concept. The disconnect lies in the fact that there is no progression between Web platform maps and how maps are implemented today.

Today’s Web map authors bridge the gap. Image credit: Science In Things

The question is how to bridge the gap? How can the platform afford HTML authors of all experiences and abilities the opportunity to create a modern Web map experience that is progressive?

In the past, such a question had an all-or-nothing answer. Either you use advanced features of the platform (scripting, WebGL, canvas, etc.), or you get nothing. Such an approach is not progressive; it is more like (graceful) degradation. In order to be relevant today, a solution must be progressive andresponsive.

Today’s answer is provided by evolving modern Web standards in the form of Custom Elements, which give us the opportunity to extend the Web platform.

Here it is. You might like to load that page in different browsers or devices, or reload having disabled JavaScript, to get the idea of how it progresses and responds. It is a work in progress, so no promises are made.

There are many detailed considerations to PE of the map element, and the Maps for HTML community seeks feedback with this post about what is best for web maps. Web Incubator Community feedback would be greatly appreciated.

The Web, Extended

There are two main design options for Custom Elements: extending the semantics of existing standard elements by with attributes and/or permitted content (a.k.a. customized built-in element e.g. <button is=”tequila-button”>Drink me! </button>) or defining entirely new elements (a.k.a. autonomous elements e.g. <taco-button>Eat me! </taco-button>). 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 and progressive enhancement is its name.

The advice of the Custom Elements spec is:

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.

If we, the Maps for HTML Community Group are successful, we will eventually have built, or caused to be built, a large set of Web sites which use our custom element(s), and it’s API. Ideally at that stage, browsers will agree that it makes sense for them to implement our element natively. If our element is ‘autonomous’, a new element (without the hyphen) will have to be minted and marketed, and all that portion of the Web which uses our element would have to be re-written to take advantage of the new reach. I suppose you might consider that a problem of success, but it also represents a barrier to adoption.

A more viable solution will be to extend the behaviour of the HTML map element as demonstrated above. Not only can the new functionality be layered appropriately for progressive enhancement, but at worst, HTML authors will have to remove the is=”web-map” attribute from their markup to gain a “native” implementation; all selectors and code not based on the “is” attribute should continue to work. That’s the theory, at least; there is a lot of work to do to see this prollyfill through to completion.

Further Progress

If creating a declarative Web map was the only goal, we would be essentially done now, because there are many such Custom Elements today. But a declarative Web map is only a starting point for progressive enhancement. Although the beauty and sophistication of today’s Web maps can’t be accomplished without a lot of scripting magic, those maps really are beautiful and sophisticated. The Web platform could provide a standard script API which enables enhancement from a common declarative starting point, and just as importantly, allows HTML (map) authors to progress from beginners to experts.

Arguably, the central innovation of the Web platform is indirection through hypertext using URLs. This allows user agents to be coded in a domain-independent fashion, applicable across the Web. It is also this aspect which underpins the type extension map element: maps and map content rely on URLs and media type semantics. The map type extension element also relieson this Web superpower. This allows authors to easily include content from different map providers “interoperably”.

That’s where community comes in.

The Maps for HTML Community Group warmly invites the authors of google-map, here-map, leaflet-map, Leaflet.js, openlayers-map, OpenLayers.js, mapbox-map, carto-map, apple-map, etc., and yourself to join us to show your support, or even contribute 😍.

Thanks to •?((¯°·._.• вкαя∂εℓℓ  and Benoît Chagnon for reviewing an early draft of this post.