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.
Group's public email, repo and wiki activity over time
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.
Ed Freyfogle, leader of the OpenCage geocoding service, and Peter Rushforth had a chat about the Maps for HTML community and our goals. You can listen to their conversation here, please leave comments below.
The Maps for HTML community development has been happening “seasonally” for a few years now, driven in large measure by student internships. We have had excellent experiences with the co-op programs of the University of Waterloo, and Ottawa University here in Canada. Students generally arrive quite new to the field of Web development, and we show them what we know and what we’re working on and let nature take its course, sustained of course by MDN and browser DevTools! The results have been very good so far, and it’s time to review some of the things we’ve undertaken this term.
Autonomous agents
In September 2022, we held a hybrid meeting of the community group, with some of us physically present and others dialled in from around the globe. There were some interesting discussions and some of those discussions have led directly to activities this term.
For example, at our F2F, we were talking about map semantics (the subject of an earlier post), and Ed noted that the visual character of a map is one thing, but what is the meaning of the thing that is depicted by the map?
Ed: How do we describe the location semantics in an html web page and make it available to the autonomous agent?
Now, semantics is a profound topic, one that is perhaps even more relevant in today’s world of AI and generated prose. Anyway, not to go down the AI chatbot rabbithole, I have posited before that the central characteristic that makes a map special, and “semantic”, is the shared definition of the coordinate reference system used by the map. Clearly, shared coordinate reference system definitions are at the heart of geospatial interoperability, but are they enough to allow HTML authors and autonomous agents to clearly differentiate, say, Paris, Ontario, from Paris, France? Certainly! But how does that translate to something meaningful for the user of a map? A visual user can see, perhaps if necessary by zooming in or out, that what is depicted is clearly in one location or the other. Similarly, the markup of a declarative web map visually and computationally places the map in Ontario, or France, or wherever. But what of non-visual users, or for that matter, autonomous agents (web crawlers) and, by extension, search engine users? What does the map mean to them? Ed was unequivocal about where the current generation of JavaScript maps leaves them.
Ed: From the point of view of an autonomous agent, what they see in the JavaScipt (web map) is invisible i.e. nothing
We strongly agree on this point! To address this problem within the scope of the MapML proposal for the Web, Kevin developed a custom element called <map-caption>. The <map-caption> element is a way of allowing the page author to describe and differentiate the map’s meaning explicitly for accessibility technology and potentially for search engine users, which may be especially important if search engines are incapable of spatial indexing. The tight coupling of the caption with the spatial focus of the map state should allow both users and crawlers to leverage map semantics to the fullest extent possible. Please, don’t be shy, hop onto our topic discussion and share your views. Nothing is standardized yet, and we want to ensure we standardize something useful to folks and their autonomous agents.
Map width and height
A long-standing need has been to lower the getting-started barrier for newcomers to HTML Web mapping, since inclusion is our central objective. Way back in the Polymer days, our polyfill supported the width and height map viewer attributes, but during Web Components 1.0 refactoring, those attributes were not carried forward. Back in 2021, Eric spent some time experimenting with our <mapml-viewer> and one of the most confusing moments of that experience was the lack of width and height attribute support, because we had come to rely on CSS being supplied for these values, and the underlying mapping engine that powers our proposal is highly dependent on having a defined container element height to work with. Even though width and heightno longer mean what they used to for HTML images, for example, they still play a role in the efficiency of the browser layout process. So, Jacky brought back the width and height attributes for use with our <mapml-viewer>, hopefully making the getting-started process a little less confusing by enabling more paths to success, and perhaps polyfilling a similar role to that played today by the <img>width and height attributes, for a future HTML map widget.
GeoJSON is Everywhere
Along the way, many people have suggested that support for GeoJSON might be essential for a standard Web map widget. After some soul searching, because we don’t want to make this proposal any larger in scope than it must be, we decided to implement a speculative polyfill for GeoJSON.
Aliyan did some nice work pulling that together, first as a library function that you had to import and later (currently) as part of the <mapml-viewer> and <layer-> element WebIDL APIs. These APIs are partly exposed as map viewer context menu option for Paste (P), which, if your clipboard is loaded with a GeoJSON feature or featurecollection text blob, will create a map layer with a default graphic and textual representation of the features. If you want to apply custom CSS styles to the map features that are generated by pasting, you can always hook your code directly into these APIs, as shown by this experiment.
Context is Everything
Hanyu dived into the CSS pool and made the behaviour of the map and layer controls’ context menus more predictable and testable, not to mention nice looking and accessible to keyboard users.
The map context menu, showing the copy submenu, and the layer context menu are shown above
One of our epics is to make MapML self-perpetuating and hackable, hopefully following in the footsteps of the “View Source” culture established by HTML. To that end, we have created user documentation and tutorials that try to help newcomers climb their learning curve. Some of the functions exposed by the right-click / Shift+F10 context menus include copying various bits of MapML markup that can be used to help you create your own maps from close to scratch.
All the user-facing functionality should be localized, and for that we turn to our browser extension, which we use to polyfill the browser chrome. In addition to localized UI, we have recently added the French language to our documentation site. Our documentation approximates for the MapML proposal what the Mozilla Developer Network docs do for HTML and Web APIs. If you are interested in making Web maps a global standard, please get in touch and potentially help the initiative by contributing your native language.
On the Road to 1.0.0
That’s all for now. We’ll have much more to say at the end of our work term, but we think we are heading towards a “1.0.0” release, which will mark a major milestone in this effort. Stay tuned. As always: new community members and contributions are always welcome.
TL;DR: “machines” use the HTML structure of Web pages to enable the coherent transmission of the document content’s meaning to the user. Maps and locations are not currently reflected in HTML’s structure, nor browser rendering engines, and so a) their meaning is proprietary to Web sites, concocted as they are, from ever-more-opaque code, and b) Web-based assistive technology, aka “machines”, are unable to follow the markup that might convey locations to users, and so the machines need hints, which are typically omitted or badly implemented. Maps and location are important for everyone, but especially important for non-visual users who must rely on textual location descriptions and search. Maps and location semantics may also be important on the Web for future applications such as the metaverse, digital twins, smart cities, the Web of Things, spatial data infrastructure, indoor mapping and autonomous vehicles, to name a few. To sustainably and fairly enable these applications on the Web, maps and location should be integrated in the browser engines, with standardised HTML semantics.
The usage of the word “semantics” in this document is distinct from that of its usage in the Semantic Web. The latter is not discussed here.
Web pages contain a mix of structure (HTML markup) and content (text, images, media, etc). Web pages are structured using HTML elements so that the “machines” that process them (browsers, screen readers, search engine crawlers, etc) understand what the parts are and can render or process them accordingly. Machines process HTML element structure, so that humans can consume and understand the meaning of the HTML contents. The standardised meaning accorded HTML elements (structure) is often described as HTML semantics, which refers to how that markup is specified and how it is intended to be processed. The contents of an HTML page also have meaning (for humans, mostly), and it is the raison d’être of browsers and assistive technology to facilitate the transmission of the images’, graphics’ and text’s meaning to the user, through graphic or other rendering techniques.
Web maps model physical space, just like words model conceptual space
In an analogous way that humans use language and text to convey ideas, Web maps describe the physical world with coordinate reference systems (CRS) and math (of course). That is, maps may reflect the real, physical world. The relation between this model and the real world can easily be experienced, right now, by anyone with a smartphone, by viewing your device’s location, rendered on a web map, as a symbol:
Map showing user location
An example of well-known CRS coordinates are provided by the WGS 843 coordinates reported for your device by its Global Positioning System (GPS) sensor. The geospatial standards community has spent decades of effort, and billions of dollars defining and standardising the details of spatial CRS, to enable geographic information to be processed and rendered by machines, for use by humans. These coordinates represent the most fundamental map semantics. The relationship between the multi-billion dollar GPS CRS system and the map on your phone is today provided exclusively by the JavaScript on the page, not by the browser engine. In other words, the browser doesn’t ‘understand’ the map, it leaves that up to each site, with a very few, very large sites dominating and brokering that space.
Extended and augmented reality (XR, AR) can also be models of reality, collectively known as the Immersive Web. The (potential) commonality between the Immersive Web and Web maps is that, to some degree, they each represent physical and virtual reality integrated together, sometimes relying on user device sensors to “place” the user into the virtual representation, as shown by both our Web map examples above. The value of placing the user into a virtual representation of reality, be it a 2D map or 3D representation, lies in the accessibility, privacy and performance delivered by HTML semantics, and rendered by browsers for the benefit of the user. Such value can only be realised only if all Web sites have a simple (declarative), open (standard) and fair way to represent physical reality that does not depend for existence on procedural browser extension (JavaScript, WebGL, WASM etc.).
Web maps require JavaScript
When everyone is responsible (for map accessibility), no one is responsible
A key argument against extending or even relying on JavaScript to deliver map and location semantics to the user (even if a non-DOM standard library did exist) is that providing accessibility for maps and location content for the Web then becomes the responsibility of individual Web sites and library developers. When everyone is responsible for creating accessible content, when that content is or must be created with JavaScript, canvas, or WebGL, or WASM, inaccessible content is often the result. Other essential characteristics of the Web besides accessibility are also lost or harmed when JavaScript is used as a substitute for HTML semantics, including: performance, generality, internationalisation, and crawl- and search-ability. In short, while JavaScript (and its sidekick JSON) is a fantastic language to progressively enhance the Web experience, it should not be looked to as a focus for Web standardisation of mapping.
Third-party Web map providers
What is “special” about spatial?
At our recent Maps for HTML community meeting in September 2022, we had the beginnings of a really interesting, and I believe important discussion, about the intimate relationship between accessibility, map semantics, and rendering. Boaz Sender, from Bocoup, showed us an example of a prototype browser intervention that they have been researching, using a dynamic Leaflet-powered, OpenStreetMap-backed map of Denver, Colorado. The “intervention” part was where the whole map, and especially the set of features highlighted on the map was rendered on request, not graphically, but in an alternate “view” representing the map as a simple text list. This seems to be a prototype implementation of a really important idea, and one that has come up before in our community, and it is an idea that is gaining traction in the mobile app world (yes, the Web Platform community should pay attention – mobile apps surpass the Web by far in location-based usage).
A Leaflet.js Web map of Denver
Ed Parsons raised what I consider to be a profound question about the Denver map example: What is it about the map, besides being visually obvious to someone familiar with United States geography, that tells us that it’s a map of Denver? Even the text list representation of the map might not indicate that these are features from Denver, and the map itself even might not be labelled as such, despite the importance of such labelling. Still, there is something significant about the meaning of that map that is instantly obvious to users of its visual rendering that is clearly missing from the current Web.
Globally shared coordinate semantics, defined by a Web standard
What’s missing is the ability to represent Denver in a way that isn’t ephemeral, nor accessible only to sighted users. What’s missing is the ability to represent and render the coordinate space of the Earth and things on Earth in a standard way that is shared by everyone. What’s missing is maps and locations in HTML, implemented and supported by Web browser engines, for everyone!
A tree has fallen in a forest. Did it make a sound?
In my next post, I’ll explore what we’re doing in the Maps for HTML Community Group to change the status quo. See you then, I hope!
This post is a bit of catch up for several months of activity. I hope it summarizes most of what we’ve worked on since about the beginning of October 2020, just after our successful workshop. If you see that I’ve left anything out, get in touch!
In Web standards, the term polyfill refers to a software package that implements a proposed or existing Web standard in JavaScript. Sometimes these libraries are needed to fill the interoperability gaps between different Web browsers’ implementation of a feature. Other times, such as this one, they are developed as a reference or pilot implementation, which resolves research questions experimentally and which provides a hands-on experience for a future standard. In this case the future standard that we’re polyfilling is a proposed extension of HTML, that we call MapML.
Accessibility Comes First
The first thing that we worked on this past fall and winter in the MapML polyfill was to improve the keyboard navigation of query and feature popups, by adding forward/backward navigation controls to the bottom of the popup. These controls prevent a keyboard-only user from getting trapped in a sequence of many features by providing fast-forward or fast-backward mechanisms. There is still work left to do, which is made a bit harder by the fact that the Leaflet project appears to be on hiatus and is not accepting pull requests.
While deep in the maps-in-the-browser polemics with @shepazu, it was agreed that while popups are a common visual UI used for map and feature interrogation, they are certainly not the only option. Further, and a sign of hope for the continued evolution of HTML in the Web Platform, there is currently a well-received proposal for a native <popup> element. As a result, we have tentatively decided to disarticulate the MapML proposal at this junction; we’ll try to specify a query/popup event, which could be emitted and handled by a native widget, but just as easily handled by a custom element or other script-based client based of the native widget. The result is a simplified MapML proposal, which we think is a win for all concerned.
The video also demonstrates the implementation of the <feature> element with a child <featurecaption> element, which allows a feature to have a consistent “accessible name“. Accessible feature names were established as a requirement of workshop participants. The <featurecaption> element is rendered by the polyfill as an aria-label attribute on the output SVG content. The <featurecaption> element allows a screen reader and mouse user alike to efficiently navigate through map features. They are supported by the polyfill, and in GeoServer you are able to map any combination of feature or coverage attributes to the element returned by GetFeature or GetFeatureInfo queries, via a ${template} substitution mechanism.
One of the big ideas that has been pushed by Maps4HTML community member @zcorpan, among others, is that the MapML proposal needs to be expressed in terms of shareable primitives (my words), in other words, provide one or more APIs. Furthermore, it is pretty clear from the experience with the <video> element and pretty much all the native controls provided by the browser, that one of the first things programmers want to do is change the UI of stuff. So one of the side projects that we started was to create a script-based client of our polyfill suite. We hope to push this work further in autumn 2021, in particular to provide an outlet for rendering the diversity of vector tile formats.
One potentially important and shareable primitive of a native element would be the projection engine that, if robust, might support a wide variety of “custom” projections via an API. We also have made a first pass at mocking up such a facility, for example, here’s an implementation of the British National Grid with data from the Ordnance Survey UK, mashed up with data from the British Geological Survey.
If you have a look at the source of that page, you’ll see the following definition of the coordinate system in use:
In GIS-land, that definition could be abbreviated to just the proj4string value (or something akin to it), which provides the parameters of the projection method. The GIS world has even gone so far as to define well-known codes that can be used to abbreviate the abbreviation, in this case EPSG:27700, which is short for the British National Grid, which is a very convenient shorthand.
Please get in touch if you have ideas about this problem on the Web; I believe this is related to best practices 6 and 12 and possibly others! MapML’s definition of Tiled Coordinate Reference System is founded on adding these parameters, and tries to obtain the convenience of the codified approach with its projection name tokens: ‘OSMTILE’, ‘WGS84’ and so forth.
Requirements Fulfillment Matrix
The Maps for HTML community’s Use Cases and Requirements for Web Maps specification is intended to be an evolving representation of what a native Web map widget would need to be able to do for users. The document’s major structures are: Use Cases, map viewer widget capabilities, and client-side / widget APIs. Operating examples of each use case are provided where possible, implemented by each of several Web mapping toolkits and/or Web map content providers. This UCR document is recognized by the browser developer community as representing the best path to success for Web maps, and it was recommended that we continue to evolve that document to the point we have got solid agreement on it from the Web mapping and Web standards interests.
At this time, the community is looking for a Web mapping-and-standards -savvy organization to pick up the important work of stewarding the UCRs and associated Fulfillment Matrix to agreement and completion. Please get in touch if you know of a company, government or NGO that might be willing to help in this area.
Browsers have included a non-spatial but accessible <map> element for more than two decades, for example, this Canadian weather map is used to provide an accessible yet simultaneously visual access to weather forecasts for communities across Canada. It uses the native <area> element to link to provincial maps and communities. The reason it is ‘non-spatial’ is because the coordinate system used by the <area coords="..."> elements is defined on the ‘client side’, by the <img> that uses the <map> to provide the visual component. In an earlier age, client side image maps were popular for graphical site layout, much like <table> used to be used for grid-based site layout, before the improved separation of semantics from style that CSS brings to the Web. Nowadays, client side image maps aren’t recommended for use, but they still maintain the accessibility advantage of simple native hyperlinks. And the beauty of that is that unlike their “modernized” counterparts, such maps form part of the non-JavaScript Web, exposing their accessible information content to users and crawlers alike.
At our workshop, we heard from some participants that HTML should include an emphatically non-spatial native element, perhaps named “slippy”, that could allow for both non-spatial AND spatial maps that support pan and zoom aka native rendering. But that doesn’t make sense. Such an element would be taking perfectly georeferenced content (from a server), be it images, or tiles, or features, and removing information from it (the georeferencing) in order to render it. Such an implementation would defeat the interoperability goals that public spatial data standards-makers have sought for decades. Indeed the Open Geospatial Consortium was founded on the notion of interoperability of spatial data so that you could overlay them and gain insight from the resulting mashup.
Since “slippy” is an ill-conceived approach, ignoring as it does HTML semantics; a more sensible path is to recognize that HTML already has an accessible yet non-spatial element that could be progressively enhanced and made slippy (natively rendered) if sufficient coordinate system metadata (in the form of attributes) is present. The benefit, besides consistent semantics, is that Web pages that have maps in them become georeferenced, spatially indexable, spatially searchable and, if the provider permits it, as the operators of spatial data infrastructures generally do, potentially mashable.
In any case, regardless of the bikeshed problem, a native element can learn from the existing Web, and employ hyperlinks to advantage, so we set out to experiment with use cases that required hyperlinks. To remain faithful to the notion of the “shared primitives” imperative, one of the core use cases is backwards-compatible (with client side image maps) -yet-slippy rendering of images which are non-spatial, with links in them. Our implementation example does not quite meet all possible requirements yet, since the base image is not a single static image or even a set of responsive images, but is a classical “tile pyramid” that is readily managed by scripted URL template techniques. On the other hand, it does provide examples of internal and external links on top of a non-spatial tile pyramid, using <feature>s with a descendant <map-a> element.
The Web as a Federation
The Web itself is a large scale federation that applies standards, such as HTTP and HTML and so on. Regardless of what technology we use to implement them, if we want to play on the Web, we need to use the standards. And what is the glue that keeps that federation together? It’s the humble hyperlink, <a>, that’s what. So, why should the thing that binds the Web together not work for maps? That’s the idea behind this experiment (you might want to use Firefox to view, since Chrome is getting persnickety about mixed content), which draws on the standards-based infrastructure of the Arctic SDI. The links in that document bind together maps of different projections, which could in theory be on different domains i.e. in different countries. The resulting usable map is federated by linking with the <map-a> feature link implementation. <map-a> is a work in progress, and probably not yet properly accessible. If you have comments or suggestions, please let us know via an issue or by any means necessary.
Changing Projection Depending on Zoom
If you’ve clicked a little bit in the previous demo, you’ve experienced changing the projection of the map when following a hyperlink. A potential requirement of maps in HTML could be changing the projection of the map based on the zoom level. This is often seen to good effect in modern Web map silos: as the user zooms the map out, the projection changes from Mercator tiles to the globe view of the Earth. So we implemented a prototype of that capability, which can be experienced if you follow the Canada link in this map, and zoom in. The map projection (and source) should change from Lambert Azimuthal Equal Area (the initial view) to (at first) another completely custom polar projection (Atlas of Canada’s Polar Wall map), and then to the Lambert Conformal Conic that forms the backbone of Canadian federal map services. If you zoom in even further, you will change sources to the public OpenStreetMap tile cache, in its Web Mercator glory. While a globe view of the Earth remains an unrealized (dream) use case, we are pursuing defining the markup semantics that will allow us to take good advantage of it when it does arrive. If you know of an organization that might be interested in contributing a globe view capability to the polyfill, do get in touch.
That’s all for now. Apologies for not writing more regularly; that is an important thing that gets forgotten in the fray. If I’ve missed anything that you can think of, please drop me a note.
Thank you
Thanks to Ahmad Yama Ayubi, for his able help in clarifying my sketchy requirements, and implementing them without the sketchiness. Much / most of the JavaScript code described in this post was conceived and developed by him.
I would like to thank Amelia Bellamy-Royds and her team, Nic Chan, Nick Fitzsimmons and Bennett Feely for their excellent work on the UCR document and the workshop web site, we definitely couldn’t have done it without you all.
Thanks also to Doug Schepers, who got into discussing the details of this proposal in a way that very few people have had the time or inclination to do; without that friendly debate I would despair.
Many many ongoing thanks are due to Robert Linder, who keeps me inspired with his determination to see accessible Web maps realized, for everyone. Robert has also made significant contributions to the overall coherence of the documents we’ve produced and his attention to detail is very much appreciated.
As an active developer of the OpenLayers mapping library, I have been working a lot on performance improvements in the rendering pipeline. Performance is usually good, but there are corner cases where the user experience is negatively affected by an unresponsive user interface. There is a new browser technology, OffscreenCanvas, which allows rendering in web workers that run in parallel to the main thread. Unfortunately it is not widely supported in mainstream browsers. In this post, I am going to show how rendering performance in OpenLayers could benefit from OffscreenCanvas.
So, the big idea is this: MapML resolves the Web Platform gap by combining map and map data semantics into a hypermedia format that is syntactically and architecturally compatible with and derived from HTML. MapML provides a standardized way for declarative HTML content to communicate with custom spatial server software (which currently use HTTP APIs based on multiple queries and responses). MapML allows map and map data semantics to be either included in HTML directly, or referred to at arbitrary URLs that describe stand-alone layers of map content, including hyper-linked annotations to further content. This allows HTML and map authors to easily create markup inline or refer to Web map content from their documents without needing procedural programming (JavaScript) to fetch and integrate data. Finally, MapML defines a DOM structure for the map content that can integrate with Cascading Style Sheets and JavaScript, in exactly the same way HTML content does.
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.
maps4html
