Mapping in HTML - a proposal for a new element
HTML HTML5 thoughts web · 18 comments · 900 words · read ~5,158 times.
This is a sketch of a proposal for a new HTML element to simplify displaying maps on a website. I'd like your comments and criticisms before I submit it.
This is born out of my frustration of using different JavaScript mapping solutions - my phone has a mapping app, why do I need to share my location with a website and their mapping provider?
At the moment, if I want to use Google Maps, or OpenStreetMap, or Carto, or any other mapping provider, I have to load in a bunch of external JavaScript and then add <div id="map"></div> to my markup.
How about we get rid of all those external libraries as a dependency? Let's do what we did with <video> and make mapping a first class element.
It's quite common to suggest new HTML elements based on popular <div id="..."> - that's how we got <nav>, <footer>, <aside>, <audio>, and the like.
I'd like to propose a new tag:
<geo>
(In an ideal world, this would use the <map> element - but that has already been taken by image maps. It could equally be called <mapping>, <maps>, or similar.)
Use cases
- As a user of a website, I want embedded maps on a website to offer a fast and consistent experience.
- As a user, I don't want to share my location with a website.
- As a user, I want access to my devices' mapping features when I view a map on the web.
- As a developer of a website, I want to take advantage of any in-built mapping software the user has, rather than use a 3rd party library.
Dive in!
This is a sketch of how a <geo> element could be used. This doesn't cover all use cases, it misses out important things, it glosses over problems. This is a prototype for others to critique.
Display a map centred on a specific location
Visit our restaurant!
<geo location="51.75026,-1.248338">
Your browser doesn't support interactive maps.
<img src="...
</geo>
Fairly simple. A block element which takes a location. It includes a fallback experience - just like the <video> element.
If the user has a mapping app installed on their device, that will be used to provide the map. That will give the user access to all the mapping features they regularly use (favourite places, routing, preferred map styles, street view).
If they don't have a mapping app installed, the browser can provide that service - or the web developer can specify a fallback solution. Just like HTML5 Video.
Location
I envisage location= as taking any data. It is up to the mapping provider to interpret it.
<geo location="Oxford, UK">
Your browser doesn't support interactive maps.
<script src="...
</geo>
Zoom
A common requirement for a map is to specify a zoom level. For example, Google Maps uses zoom levels 0 - 20 - with being fully zoomed out. Similarly, OpenStreetMap uses 0 - 19.
Rather than arbitrary numbers to represent zoom, the <geo> element uses a zoom tag which defines how wide the map is in measurable units. For example zoom="5KM" shows a map with a diameter of 5 kilometres. zoom="90deg" shows a map zoomed out to show quarter of the world.
<geo location="51.75026,-1.248338" zoom="10KM">
Your browser doesn't support interactive maps.
<img src="..." />
</geo>
Possible values could include degrees, kilometres, metres, and metres per pixel.
Interactivity
A website owner may not want a "slippy map" experience - in order to create a map which can't be moved or zoomed, they can use the boolean attribute static.
<geo location="51.75026,-1.248338" zoom="10deg" static ></geo>
Markers
It is useful to put a selection of markers on a map. For example, the location of the entrance points to a venue.
<geo location="日本武道館" >
<marker location="35.69391,139.7494" display="entrance">
<img src="...">
</marker>
<marker location="35.69274,139.7501" display="exit"></marker>
</geo>
In this case, the markers have a location tag, with an optional display tag for textual representation. They also have an optional child which contains an image to be used as the marker.
Directions
In this example, the map shows directions from the user to the destination.
Have a drink with us:
<geo location="Strangers' Bar, SW1A 0AA, UK" directions></geo>
A boolean tag. Crucially, the <geo> element doesn't share the user's location with the website.
Complex data (KML and geoJSON)
Both KML and geoJSON are popular ways of expressing complex spatial data. It should be possible to pass that data to the mapping software via the src= parameter.
<geo src="/data/points.json"></geo>
<geo src="/data/points.kml"></geo>
Other Stuff
Wait! What about....? As I said, this is a basic skeleton description of a new element. It probably doesn't involve your specific use case.
Just like the <video> element, this doesn't stop a developer using a 3rd party solution if they want.
Your thoughts?
The usability of HTML elements
Having thought about it a bit more since my tweet when you first suggested the idea, here are my musings:
This would leave you beholden to which ever mapping/tile provider that browser chose to use. Each of the mapping providers differ in quality and in the types (e.g. not all include satellite photos) of tiles they provide and how often they are updated. This means that you will get differing look and feel between browers which isn't great and adds to testing.
I also wonder what this would do to the Map provider market, I would guess that Chrome would default to Google Maps, IE/Edge would opt for Bing Maps and Safari for Apple Maps. Leaving Firefox and Opera as wildcards, would Google or Microsoft try and entice them use their platforms as they do with default search providers? Would it be configurable, like search providers? What would this do to the likes of OpenStreetmap?
Also to make use of Google Maps tiles you need a API key for "commercial" use iirc which would make life tricky as it would mean the browser teams would need to come to an arrangement with Google who are probably the current "default" map provider for many.
The video tag was a little different because it basically replaced flash which had a whole raft of reasons (mainly security) for needing to die and we still had/have the issue of which browsers support what codecs (and the licensing issues round those)
Terence Eden says:
Reasonable points. However the majority of devices which access the Web already have a mapping app built in.
Developers already have to do the dance of signing up for API keys, this redistributes the work back to browsers.
And, as I hope I made clear (but possibly didn't) this wouldn't stop developers from using whichever mapping provider they wanted. They can still pull in 3rd party maps - just the same as they can do for video or audio.
"not all include satellite photos"
We'd need some sort of fallback: "display a satellite view if you can, if not, display a topographical map; if not, display a street map"
This could even be a user setting: "If a satellite map is specified, use Google; if a street map is specified, use OSM".
I think it would be useful for tag to have separate location and display attributes like does.
Relying on map provider's interpretation of human-readable location may not work well in some areas, so people will surely want to specify precise coordinates. On the other hand, if the map provider chooses to display received location on top of the map (for example, in the corner), a human-readable name would be better in this place. That's why I think it's better to have both either-machine-or-human-readable location attribute and a human-readable and elegant display attribute.
Putting a heading on top of the map like this could also be done with CSS, I suppose, but it will not look as good on every device as it would if the map component was to render it itself.
In case you missed it on Twitter, turns out someone is already keen on this idea, and there's even a whole hashtag for it! https://twitter.com/prushforth/status/900740519562760193
This sounds like a use case for Web Components, which lets JavaScript define a custom element and how to implement it.
https://developers.google.com/web/fundamentals/architecture/building-components/customelements
Web Components must contain a hyphen, to disambiguate them from built-in elements, so you'd need to pick a tag like . Then your JavaScript library would be responsible for interpreting that element into normal elements in the shadow DOM.
Pietje says:
Interesting idea. Two thoughts that come to mind after reading your post:
(1) Parameters for styling. Besides being able to use CSS for defining the height, width, positioning, etc. of the 'geo' element, as a web designer/developer you might want to have some influence on how the map itself looks, in case you want to match it with the design of your site. For example, whether to use satellite imagery instead of a map; if names should be displayed for streets, buildings, areas, etc.; colouring for roads, routes and other elements.
(2) If the 'location' attribute is to accept any data, maybe a (non-intrusive) fallback needs to be defined in case the mapping app fails to match the data to actual coordinates. It would be a bad user experience if you open a website and you get a pop-up from your mapping app saying "location not found" because of an embedded map.
"as a web designer/developer you might want to have some influence on how the map itself looks"
Remember that OSM is a database of geo-spatial points and ways. It's theoretically possible for a browser to be given the bounding box and styles, fetch the data, and render the map on the fly. In practice, organisations (like the Wikimedia foundation, for instance) build map tiles to their own specifications, then serve them from a cache.
Richard Fairhurst says:
"It's theoretically possible for a browser to be given the bounding box and styles, fetch the data, and render the map on the fly."
Much more than theoretical: this is how vector tiles work, which is basically 90% of the Mapbox rendering product, as well as the technology used by Google and Apple. Server-side rendering of raster map images is (slowly) on the way out.
Andrew McGlashan says:
Sounds good; an alt tag for text describing the location, perhaps, like images? I would love for the browser to have an option to use OSM by default (or, as has been said, make this configurable like search) with an option to fall back to other choices easily, again like search. I also hate how Google gets markers and information about visitors simply because Cloudfare uses Google for most captchas -- I wish they would create and use their own captcha and allow us more freedom from Google collecting all the data.
Great idea, and I'd be willing to participate in any discussion, say on a W3C mailing list, to take it further.
It's worth noting the work of the Spatial Data on the Web Working Group[1]
There are also some similarities with the "Geo" microformat [2], which relies on the visible display of coordinates, and that mode might even be a good fallback when a map service is not available.
We'd need a way to specify the CRS (Coordinate Reference System), assuming WGS84 is the default - not least so we can say that a point is on the Moon, or Mars, or wherever, and have the browser display an appropriate map in such cases.
The zoom level might be adjusted according to the user's location: "how to get here" varies if you're three blocks or three miles away, for example. It should also be possible to instruct the browser to put a marker on the map for the user's current location; and/ or to enter "directions" mode and show a route.
It might also be sensible to allow the author to specify the coordinates of a bounding box (say, top-right and bottom left), and have the browser display a map zoomed according to the size of the available viewport.
[1] https://www.w3.org/2015/spatial/wiki/Main_Page
[2] https://en.wikipedia.org/wiki/Geo_(microformat)
Trying again (bad connection from the cottage). The Maps For HTML Community Group is working on pretty much this concept. We would love contributions from everyone here. We have published a custom element here, which would be great for you to check out for yourself https://www.webcomponents.org/element/Maps4HTML/Web-Map-Custom-Element. We are developing MapML, or Map Markup Language as a way of allowing mashups using simple URLs. There is lots of potential.
Final note I think the map element is actually a good choice as it would enable progressive enhancement of the existing map element for older browsers (see blog post here for a demonstration of that ideahttp://maps4html.github.io/Web-Map-Custom-Element/blog/progressive-web-maps.html)
Jason says:
Seems like a great deal of what you've written here is duplicated by https://github.com/Maps4HTML, and that it would be worth reaching out to that community.
Brilliant idea: I could have done with this today.
Please could we have arbitrary HTML in the ... tag? Those things always need different info and styles for different projects. And can we keep units lowercase ("50km")?
I wonder if there's a way of exposing map styles to CSS? Like how you can style SVG inside HTML, it would be neat to be able to do that to the map.
I hereby offer as an alternative name.
Meh; That was "Carto", in angle brackets.
I also recommend the https://wordpress.org/plugins/simple-comment-editing/ plugin!
ukmoose says:
I must have missed this the first time around. One challenge is that a lat long does not uniquely define a location. To do that you need to also specify a spheroid. There are many different spheroids in use, most often WGS84, but not always.
As web technology is often abused for other uses than originally intended, not specifying a spheroid might not make much of a difference to someone trying to locate a restaurant, but in other fields a mistake in the spheroids-used can have expensive consequences. There are examples where wells have been drilled outside of the area licensed for exploration, with the company forced to drill another well inside their licensed area in order to meet a work commitment.