The Maps in HTML Community Group seeks to establish at least one hypermedia type which can be considered to be consumed by a (new) "map" element for HTML. Follow-on from Bar Camp at #lgd14. The objective will be to define a hypermedia type which can be linked to from a hypothetical (but prototyped in Web Components) "map" or (geo-map for Web Components) element which will provide simple mashup capabilities and user interface.
Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
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.
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.
<-- 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 hidden 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/en/osmtile/osm/" label="Open Street Map" checked hidden></layer->
<layer- id="marker" label="Marker layer" src="marker.mapml"></layer->
<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="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">
<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;">
</map>
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 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.
Maps for HTML was the subject of a paper presented by Peter Rushforth (slides) at the Location Web 2016 workshop, which was part of the WWW2016 conference in Montreal, April 11-15.
New post today about the GeoWeb here. The topic is the intersection of interests of the Web and Web mapping communities, and so can be a bit hard to think about because you have to put yourself (in most cases) in the other person’s shoes.
There is a new Maps4HTML organization on GitHub, dedicated to the use of the Maps For HTML Community Group. Every member of this Community Group has received an invitation to join the members team on that organization. Members can create repos associated to the organization.
A key factor in the success of any Web standard is community. To that end, if you accept the invitation to join the Maps4HTML community on GitHub, please consider making that fact public. Your presence on the front page of the organization will help drive other interested people and companies to join us.
The objective of the Maps4HTML organization on Github is to help us collaborate not just on ideas, but on actual specification and implementations of those ideas. You will find a few repos already there which may help stimulate more ideas and prototyping. Go for(k) it!
Standards are hard. Just ask anyone who has been in the trenches of standards organizations working for the Web. Getting agreement on technical subjects requires a lot of effort, on the part of individuals and organizations. The broader in scope the intended standard, the greater is the requirement for simple, clear language, meaning and function. Importantly, the greater is the requirement for diverse community input, if not agreement.
The Maps For HTML Community Group is dedicated to the development of Web standards which support Web mapping, which with your help, will lead to integration of maps into the Web platform.
Please join us, and contribute to the grassroots of the Web mapping standards development process!
A new document discussing the use cases and requirements for Web maps is available for review and feedback. Please review and discuss on the public-maps4html@w3.org list.
This is a community initiative. This group was originally proposed on 2014-03-06 by Peter Rushforth. The following people supported its creation: Peter Rushforth, Alistair Phillips, Philippe Duchesne, Ethan Dagner, Andrea Perego. W3C’s hosting of this group does not imply endorsement of its activities.