Skip to toolbar

Community & Business Groups

Maps For HTML Community Group

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.

No Reports Yet Published

Learn more about publishing.

Chairs, when logged in, may publish draft and final reports. Please see report requirements.

This group does not have a Chair and thus cannot publish new reports. Learn how to choose a Chair.

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.

Mountain goat on a cliff

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.

Maps4HTML is on GitHub

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!

Please feel free to discuss existing repos either as issues or on the Web Incubator Community Group Discourse forum for Web mapping.  Demonstrating community support for a standard is as important as specifications and implementations.

Let’s get the geo-Web moving again!


New forum to discuss standardization of Web maps

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 Web Incubator Community Group (WICG) was created from the successful experience of the Responsive Images Community Group, in order to facilitate broader contribution to the development of Web standards that respond to community needs.

Realizing that mailing lists are not always the most productive environment in which to develop standards, the WICG hosts a discussion resource for the Web standards community based on the Discourse platform, and they have graciously accepted to host a category dedicated to Web mapping for the use of our and related communities.

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!

Call for Participation in Maps For HTML Community Group

The Maps For HTML Community Group has been launched:

Let’s Share What We Know About Where We Live.

In order to join the group, you will need a W3C account.

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.

The group now has access to W3C-hosted services for email, blog, wikis, irc, tracking tools, and more. Read more about tools and services available by default and upon request.

If you believe that there is an issue with this group that requires the attention of the W3C staff, please send us email on

Thank you,
W3C Community Development Team