{"id":30,"date":"2016-10-02T19:09:29","date_gmt":"2016-10-02T19:09:29","guid":{"rendered":"https:\/\/www.w3.org\/community\/maps4html\/?p=30"},"modified":"2020-04-12T20:07:10","modified_gmt":"2020-04-12T20:07:10","slug":"progressive-web-maps","status":"publish","type":"post","link":"https:\/\/www.w3.org\/community\/maps4html\/2016\/10\/02\/progressive-web-maps\/","title":{"rendered":"Progressive Web Maps"},"content":{"rendered":"

Progressive Enhancement is at the heart of the Web. The Maps for HTML Community Group is making PE work for maps.<\/em><\/p>\n

Progressive Enhancement<\/h3>\n

Progressive enhancement is a well-established practice<\/a>. 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.<\/p>\n

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.<\/p>\n

Similarly, progressive enhancement can also apply to the Web author experience. HTML authors don\u2019t 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.<\/p>\n

\"Fractals\"<\/a><\/p>\n

Image credit: Wikipedia<\/a><\/p>\n

Progressive Web\u00a0Maps<\/h3>\n

So, how does all this relate to Web maps? On today\u2019s Web, there is a major disconnect between the map experience that most or all of us are familiar with<\/a> 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\u00a0Web platform maps<\/a> and how maps are implemented<\/a> today<\/a>.<\/p>\n

\"Mountain<\/p>\n

Today\u2019s Web map authors bridge the gap. Image credit: Science In Things<\/a><\/p>\n

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?<\/p>\n

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<\/a>.<\/p>\n

Today\u2019s answer is provided by evolving modern Web standards in the form of Custom Elements, which give us the opportunity to extend the Web platform<\/a>.<\/p>\n

<-- You will see the old image map behaviour if: -->\n<-- * you're using an IE browser, this page should force IE7 mode -->\n<-- * in FireFox, if Web Components are enabled, I believe the HTML import for the map custom element won't work -->\n<-- * in any browser if you disable javascript -->\n<-- else the map@is=web-map should have custom behaviour, including zoom, pan, layers, controls etc. -->\n<-- The img element is only used for fallback processing, otherwise it is hidden by the custom element on load -->\n<img usemap=\"#dowslake\" src=\"map1.png\" width=\"700\" height=\"400\" alt=\"Dow's Lake area\" \/>\n<-- The map element can be set up by the HTML author to provide the old image map behaviour -->\n<map name=\"dowslake\" is=\"web-map\" zoom=\"17\" lat=\"45.398043\" lon=\"-75.70683\" width=\"700\" height=\"400\" controls hidden>\n  <layer- id=\"osm\" src=\"http:\/\/geogratis.gc.ca\/mapml\/en\/osmtile\/osm\/\" label=\"Open Street Map\" checked hidden><\/layer->\n  <layer- id=\"marker\" label=\"Marker layer\" src=\"marker.mapml\"><\/layer->\n  <area is=\"map-area\" href='http:\/\/example.com\/marker\/' alt=\"Marker\" coords=\"255,145,275,190\" shape=\"rect\" style=\"fill: none\">\n  <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\">\n  <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\">\n  <area is=\"map-area\" id=\"line\" href='http:\/\/example.com\/line\/' alt=\"Line\" coords=\"275,275,540,107\" shape=\"line\">\n  <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\">\n  <area is=\"map-area\" id=\"hole\" coords=\"250,250,7\" shape=\"circle\" style=\"fill: blue; stroke: none;fill-opacity: 0.3;\">\n<\/map><\/pre>\n
\"map1\"<\/a><\/p>\n
Here it is<\/a>. 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.<\/p>\n
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<\/a> would be greatly appreciated.<\/p>\n
The Web,\u00a0Extended<\/h3>\n
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=\u201dtequila-button\u201d>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<\/a> which suggests<\/a> that the former approach provides better value to the Web platform and progressive enhancement is its name.<\/p>\n
The advice<\/a> of the Custom Elements spec is:<\/p>\n
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.<\/p><\/blockquote>\n
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\u2019s API. Ideally at that stage, browsers will agree that it makes sense for them to implement our element natively. If our element is \u2018autonomous\u2019, 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.<\/p>\n
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=\u201dweb-map\u201d attribute from their markup to gain a \u201cnative\u201d implementation; all selectors and code not based on the \u201cis\u201d attribute should continue to work. That\u2019s the theory, at least; there is a lot of work to do to see this prollyfill through to completion<\/a>.<\/p>\n
Further\u00a0Progress<\/h3>\n
If creating a declarative Web map was the only goal, we would be essentially done now, because there are many such Custom Elements today<\/a>. But a declarative Web map is only a starting point for progressive enhancement. Although the beauty and sophistication of today\u2019s Web maps can\u2019t be accomplished without a lot of scripting magic, those maps really are<\/em> 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.<\/p>\n
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 relies<\/a>on this Web superpower. This allows authors to easily include content from different map providers \u201cinteroperably\u201d.<\/p>\n
That\u2019s where community comes in.<\/p>\n
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<\/a> to show your support, or even contribute<\/a> \ud83d\ude0d.<\/p>\n
Thanks to \u2022?((\u00af\u00b0\u00b7._.\u2022 \u0432\u043a\u03b1\u044f\u2202\u03b5\u2113\u2113<\/a>\u00a0 and Beno\u00eet Chagnon for reviewing an early draft of this post.<\/p>\n","protected":false},"excerpt":{"rendered":"
Progressive Enhancement is at the heart of the Web. The Maps for HTML Community Group is making PE work for maps.<\/p>\n","protected":false},"author":2111,"featured_media":31,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_s2mail":"yes","footnotes":""},"categories":[1],"tags":[7,5,6],"class_list":["post-30","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized","tag-javascript","tag-progressive-enhancement","tag-web-maps"],"_links":{"self":[{"href":"https:\/\/www.w3.org\/community\/maps4html\/wp-json\/wp\/v2\/posts\/30","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.w3.org\/community\/maps4html\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.w3.org\/community\/maps4html\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.w3.org\/community\/maps4html\/wp-json\/wp\/v2\/users\/2111"}],"replies":[{"embeddable":true,"href":"https:\/\/www.w3.org\/community\/maps4html\/wp-json\/wp\/v2\/comments?post=30"}],"version-history":[{"count":7,"href":"https:\/\/www.w3.org\/community\/maps4html\/wp-json\/wp\/v2\/posts\/30\/revisions"}],"predecessor-version":[{"id":93,"href":"https:\/\/www.w3.org\/community\/maps4html\/wp-json\/wp\/v2\/posts\/30\/revisions\/93"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.w3.org\/community\/maps4html\/wp-json\/wp\/v2\/media\/31"}],"wp:attachment":[{"href":"https:\/\/www.w3.org\/community\/maps4html\/wp-json\/wp\/v2\/media?parent=30"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.w3.org\/community\/maps4html\/wp-json\/wp\/v2\/categories?post=30"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.w3.org\/community\/maps4html\/wp-json\/wp\/v2\/tags?post=30"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}