
Mapping in HTML – A Proposal for a New Element - ateesdalejr
https://shkspr.mobi/blog/2017/08/mapping-in-html-a-proposal-for-a-new-element/
======
ricardobeat
This is the exact use case for web components, except it doesn’t require
browsers shipping their own implementation and updates - it’s all in userland.

Example: [https://www.webcomponents.org/element/keanulee/good-
map](https://www.webcomponents.org/element/keanulee/good-map)

~~~
aphextron
Agreed. There should (and probably will) never be another new element added to
the spec after HTML5.

~~~
zeveb
That's a remarkable perspective, and one I happen to disagree with. The great
thing about standardising elements is that we can standardise behaviour
without having to grant every server in the world execute access on clients.
HTML _can_ be used simply as a bootloader to start up a JavaScript DOM-
manipulator, but it _shouldn 't_ be, because it is far more secure and private
to read a static web page than it is to execute untrusted code.

------
j4ybee
A long time ago, in a galaxy far, far away, I worked with some guys who put
together an incredible proposal to ICANN for a new .geo TLD:
[http://www.ai.sri.com/dotgeo/](http://www.ai.sri.com/dotgeo/)

The proposal was not accepted, but .aero and .museum were, and we all now how
those have since utterly revolutionized the internet.

~~~
shabbyrobe
Neat! Speaking of galaxy far, far away, the executive summary only mentions
other planets in passing. I couldn't quite grok from scanning how you might
access cells from the moon with this TLD.

.aero may be questionable, but surely the boundless usefulness of .ninja or
.moe isn't in dispute?

~~~
j4ybee
yeah, those came a little later, but 2000 was the first year ICANN was ready
to accept proposals for TLDs beyond the original 7. They made a call for
innovative new uses of the domain system. My colleagues proposed .geo, ICANN
went with .biz, .info, .name, .pro, .aero, .coop, and .museum.

Full list of proposals that year here: [http://archive.icann.org/en/tlds/app-
index.htm](http://archive.icann.org/en/tlds/app-index.htm)

~~~
shabbyrobe
Oh, I was joking about .moe, etc - I reckon .geo would be far more useful!

But my main question about the moon was quite serious - how would you access
the moon with this? I couldn't quite understand how this part from the
executive summary would translate to an actual DNS request:

"One special GeoRegistry must have a server assigned to every cell on the
planet. This GeoRegistry will be called the default GeoRegistry named "earth."
(The names of the other planets will be reserved for interplanetary geodata.)
The default GeoRegistry will be used when client queries do not specify a
GeoRegistry name, or when the specified GeoRegistry does not have an assigned
cell server."

Kinda cool that .geo predates Google Maps by about 4 or 5 years!

~~~
j4ybee
the overall program also included a 3D terrain browser built on top of .geo
that pre-dated Google Earth by 4 or 5 years.

[http://www.ai.sri.com/digital-earth/](http://www.ai.sri.com/digital-earth/)

those were great times... sadly, the Principal Investigator passed away, one
of the lead devs left the company for greener (for-profit) pastures, and the
program was de-funded when DARPA priorities shifted post-9/11 and it all just
kinda evaporated.

re: the moon - I honestly forget how that part was supposed to work....

------
tmcw
The solution proposed doesn't match the problems stated, or take much of the
technical realities into consideration. Which is fine - maps are complicated,
and hard to understand.

\- As a user, I don't want to share my location with a website.

The proposed element doesn't seem to address this at all, or suggest how it
might address the problem down the line. Even if there was some sort of opaque
position-in-the-browser-but-not-sent, how would, say, nearby businesses show
up?

\- As a user, I want access to my devices' mapping features when I view a map
on the web.

You already do, with the W3 and WHATWG standard protocols in every browser.

\- 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.

Like what? People don't have built-in mapping software installed on their
computers.

The 'zoom as width of map' proposal is, um, well - as I said, maps are
complicated. It's not a very good idea.

Anyway, the state of the art is pretty much:

\- Use Leaflet and you can have your choice of mapping providers.

\- There are good standards like GeoJSON and navigator.geolocation to move
data around.

This concern has come up before - like there was, long ago, the mapstraction
project that 'abstracted' away mapping providers. It's abandoned, for pretty
good reason.

~~~
mcphage
> Even if there was some sort of opaque position-in-the-browser-but-not-sent,
> how would, say, nearby businesses show up?

The tag would contain (or link to) a listing of locations, and the map could
choose to display nearby ones.

> People don't have built-in mapping software installed on their computers.

Some do (Macs, for instance), but I think the author was proposing that the
browsers themselves would implement the mapping component—Google would use
Google Maps, Safari would use Apple Maps, Microsoft could use Bing Maps, Opera
could use OpenStreetMap or work something out with another map provider.

> 'zoom as width of map' proposal is, um, well - as I said, maps are
> complicated. It's not a very good idea.

What's the issue with this one?

~~~
ubernostrum
There is no way to have a web-document-embedded map that can usefully show a
user things near their device's location without leaking that location to any
entity with access to execute JavaScript in the context of that document.

Browsers have had to learn the hard way that getComputedStyle and even the
animation timing APIs are essentially un-close-able privacy leaks (hell, even
HSTS is abusable as a way to set and check "supercookies"). Any useful map
would have similar problems.

~~~
LordDragonfang
>getComputedStyle

It looks like Firefox actually closed those security holes a while ago[1], and
WC3 changed the standard to reflect this.

[1] [http://www.h-online.com/security/news/item/Firefox-
developer...](http://www.h-online.com/security/news/item/Firefox-developers-
block-old-CSS-leak-968670.html)

~~~
ubernostrum
Simple use of :visited has been closed off, yes, but that actually took
multiple attempts. See this bug, for example:

[https://bugzilla.mozilla.org/show_bug.cgi?id=557287](https://bugzilla.mozilla.org/show_bug.cgi?id=557287)

And about a year ago it was discovered that in Microsoft Edge the :visited
hack was alive and well again.

And that's still very far from fixing the problem. There are still
occasionally properties which pop up that are accessible and can reveal
visited/unvisited state. There were a whole bunch of background-image tricks
where observing what image was requested from the server side would tell you
visited/unvisited. There have been timing attacks which could reveal recently-
visited sites based on load times (faster when coming from browser cache).

Then there are the the techniques which use animation APIs and still work
today. The core of the trick there is to 1) get a link in the page which you
know will use unvisited style, 2) register a callback for the next repaint
with requestAnimationFrame(), 3) change the link to point at the URL you want
to test, and 4) see if your callback executes (which indicates the link was
repainted to a different style due to now pointing at a visited URL).

The ability to do visited/unvisited styles differently, along with the style-
inspection and timing APIs, while useful, are basically always going to
provide ways to do this. If you poke around you'll find that aside from the
most basic variants there's a tendency for these reports to end up closed out
or just left in limbo forever because there's no practical way to close off
the privacy leaks they create.

~~~
mcphage
Right now everything with maps is completely wide open. So if they added a
feature which provided security most of the time, but which sometimes leaks
information if you jump through the right hoops, that’s still 100x better than
where we are today.

You’ll note that nobody is using the existence of requestAnimationFrame()
exploits to argue we should just _give_ sites whatever browsing history they
want—yet that’s what you’re arguing here for location history.

------
temporallobe
As a (partial) GIS engineer who has worked extensively with ESRI and the like,
I can assure you that this is pretty silly. Maps are deceptively complex and
require tons of data and cpu cycles. And of course they depend on a back-end
server of some kind, internal or external. Now, maybe Chrome could support
this natively to use Google Maps, but to make it part of the HTML spec is
bordering on the absurd.

------
kojoru
I think Apple might like that with their privacy stance. It really does
increase the user's privacy by never sharing the location with external
parties.

It will also simplify things for the developers in simple use cases and offer
more integration like "jump to native maps" etc

------
dfabulich
Probably the biggest problem with this idea is that all of the major geocoding
facilities, including Google, say in their terms of service that you're only
allowed to use their lat/longs on their own maps. You're not allowed to use
Google's API to get the lat/long of an address and show it on a Bing map, but
that's exactly what you'd do if Microsoft Edge offered a <map> element.

Furthermore, in addition to violating the geocoders' TOS, the lat/longs won't
look right on each others' maps. Lat/longs are hard; maps don't line up
perfectly. Lat/longs are relative to your mapping provider.

Just use their SDK, OK?

------
betenoire
If this is just "contact us" style maps, I couldn't agree more.

But what good is a map that I can't customize to my use cases, to make it
useful in my web app? How would I say, suggest restaurants nearby?

~~~
maxerickson
Presumably by dynamically adding (and styling) markers.

~~~
ravenstine
Possibly, but how often are markers useful unless the zoom factor is close
enough to show streets or landmarks? Browsers could come shipped with basic
country maps, but anything more granular than maybe state/province level is
subject to frequent change.

~~~
eadmund
If only there were some way for browsers to request content like maps
dynamically, or to refresh their maps from servers …

------
gpsx
I can imagine one way of doing this, but I am not sure it serves the purpose
the original poster had in mind. There are geo display formats, such as KML.
There could be a tag to display a KML document, much like you can display an
SVG. Geo formats are more typically data formats rather than display formats.
One of the more popular ones is GeoJSON. This is only data with no rendering
information. There could be a tag to display a GeoJSON if there was also a
format for styling, such as a GeoJSON style sheet.

This type of tag could be slightly more interesting than something like a
plain SVG tag because multiple GeoJSONs could be displayed together, as
layers, with there relative positioning given by the geo coordinates.

I think this would be a workable tag, in the sense that it does not require
content other than the GEO content provided on the page. To comment on geo
content, as some others have mentioned, most map data is proprietary. For
example the street data required to give turn by turn directions is difficult
to attain and companies charge money, one way or another for this. And, on top
of this, for better directions real time traffic information is very helpful.
This is definitely getting into the area of content rather than the type of
services I expect from a web browser.

So without the services like geocoding and directions, I am not sure if this
is what the op had in mind. I personally don't know if this use case is common
enough to merit its own tag. I think javascript libraries do a pretty good job
with this.

------
masswerk
IMHO, the analogy to the video tag made in the proposal is rather far fetched:
The video tag is still about embedding an external source, rather a natural
extension of the image tag. As opposed to this, a "geo" tag would be
requesting the browser to embed a native application of its own resources and
linked to a dedicated remote backend – which would be rather a new thing.
(With the notable exception of the Web Speech API, which does mostly the
same.) Also, map services and especially name-to-location resolving don't come
for free. Politically, this would move us away another step from the browser
as the light-weight client, it once was, thus raising the bar for any new
entries to the market by moving the browser towards a complete operating
system with included apps and mandatory remote services. (Add a "doc" tag and
a "cal" tag – and what you get is pretty much ChromeOS.)

On the other hand, if it's really just about accessing apps already installed
on the client system, what about a "geo:" pseudo-protocol, without embedding?

------
ben174
Oh come on! We've gotten ourselves into messes like this before, please have
the foresight to add a "planet" attribute.

~~~
Mz
Wouldn't that get messy quick? If we go there, don't we also need to have
catalogs of maps by date for every planet?

(No, not kidding.)

------
flukus
Why not something more like RSS that can be opened in a real app instead of a
browser widget? I believe google earth has something similar already. Then we
get to choose the best map application (or have several) and we don't have to
say "well I like firefox but the maps aren't as good as chrome".

------
callumlocke
This would be either too limited to be useful, or too complex for browser
vendors to implement.

------
krapp
I don't think this deserves its own element, existing mapping solutions do the
job well enough, arguably better than a dedicated HTML tag, and it's not a
very common, generic element like images or video.

------
Operyl
Ok, so you’re forcing the browser to use their own implementation of it. But
google charges for their mapping APIs, and I doubt they’d want to use
something like the various open source map tiles in chrome.

------
iamleppert
Clearly you haven't heard of leaflet if you're complaining about maps. It's
dead simple and has a beautifully elegant API.

------
perilunar
What's wrong with just using the object tag?

E.g.:

<object data="map.svg#somelocation"></object>

------
ArchReaper
Is this suggesting that this would rely on browser implementation?

... Is this serious?

What motivation do browser-creators have to implement this? Google wants the
javascript widget so they can properly track everything, among other reasons.
Who would back this? Who would develop this?

This isn't like playing a media file, this is a highly interactive piece of
content, with a metric shitload of complexity behind it. I don't think the
author really understands the scope of what he is asking.

Although if you feel I'm mistaken, please enlighten me.

~~~
paulddraper
> 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.

The difference is that you really _can 't_ do <video> very well without
<video>. Handling encodings, using video hardware, being energy
efficient...this is a lot of low-level graphics stuff. It's a primitive.

In contrast, you can make a map with JS and SVG/canvas/WebGL as good as a
browser could do it.

~~~
nebulous1
more importantly, <video> doesn't require a 3rd party service

------
dang
Please don't put Show HN on blog posts or things you didn't make.

[https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)

~~~
ateesdalejr
Oops... Sorry. I'll switch that now. Edit: nevermind that's been done already
my bad. :/

