Mapping in HTML – A Proposal for a New Element
shkspr.mobi
shkspr.mobi
Example: https://www.webcomponents.org/element/keanulee/good-map
I’m cautiously in favour of making a standardised map canvas element, without any form of geocoding (thus reducing its usefulness, admittedly), leaving it to a web component to handle geocoding through any particular provider.
Web components have been able to do that since before web components existed: https://developer.mozilla.org/en-US/docs/Web/API/Geolocation . It's almost as old as <canvas>.
'Userland' isn't really the right word here: web components aren't from my land; they just execute there — they are from some server.
And that's the problem: to display a map (which is, really, just an image, something HTML has been able to display inline since the late 90s) I have to grant execute permissions on my computer to some random piece of JavaScript written by a programmer of unknown competence and beneficence, and reviewed by precisely no-one.
If it's in-browser, the implementation is auditable. It doesn't change on a per-page-load basis. It doesn't require JavaScript. It can be made to work for anyone, on any platform (even if all 'work' means on a particular platform is 'there's a map of $LAT, $LONG here'). It is far less likely to be an intrusion vector. It is far less likely to violate my privacy. It is far less likely to beacon to half a dozen advertisers.
JavaScript isn't just killing the Web: it's murdering it. I sometimes think that JavaScript developers would like to just get rid of HTML entirely: just build the entire page dynamically. HTML is just their bootloader.
Well, the DOM is still useful. Controlling all rendering using a canvas is going too far for most things. But yes, the actual serialised HTML that the browser loads is commonly merely bootstrapping.
The proposal was not accepted, but .aero and .museum were, and we all now how those have since utterly revolutionized the internet.
.aero may be questionable, but surely the boundless usefulness of .ninja or .moe isn't in dispute?
Full list of proposals that year here: http://archive.icann.org/en/tlds/app-index.htm
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!
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....
- 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.
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?
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.
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...
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.
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.
So disable JavaScript. A web-document-embedded map in a browser which doesn't execute JavaScript wouldn't leak user location.
This isn't an argument against a map element; it's an argument against JavaScript. Which is fine with me: I think that JavaScript is the drug-resistant syphilis of the web. It's been an unmitigated disaster for privacy & security.
Actually, I think the substantial majority of users do now; recent macOS, Windows 10, iOS, most Android—and having browsers fall back to using an existing mapping website (similar to its being an iframe) would not be terribly difficult.
It will also simplify things for the developers in simple use cases and offer more integration like "jump to native maps" etc
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?
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?
That's a big crux of the article, the browser shouldn't have/get to know where you are.
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.
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?
(No, not kidding.)
When you can delete a planet and fire up a fresh instance quickly, lat/long might get tricky.
E.g.:
<object data="map.svg#somelocation"></object>
... 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.
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.
"Who would back this? Who would develop this?" These are the same questions that the author is asking.
I agree it seems unlikely this feature would be very useful. Your post however is even less useful than a well articulated idea. This comment you made actually adds negative value due in part to nonsense hyperbole like "metric shitload of complexity," failing to dive into meaningful details.
More specifically, it's a highly interactive piece of content, with a metric shitload complexity behind it, that's currently implemented entirely in javascript. From that perspective, turning it into a native browser component seems like a good idea.
And your argument regarding companies wanting javascript so they can track everything goes equally for the video tag as well.
Though I agree the interaction with maps is different from video, how about we first give the poster credit for recognizing a problem/opportunity.
Ok, so let's say it is a real browser implementation. My first reaction was "but the map imagery providers all want to get paid for their content. I had assumed this meant the browser being built in with the map content, but that "might" not be the case.
Google, Microsoft and Apple all already have their own mapping solutions, so each browser "could" use those services by default. Otherwise, the website owner still needs to decide which mapping service to license.
Map tile loading and navigation is mostly (it seems) a solved problem, much like video is. Even 3d mapping for the most part seems to have fallen into common navigation schemes (though there is room for improvement).
So now, what is so out of scope? Layers? Common across platforms, why not? Directions, sure.
What are we missing that you think would be so impossible.