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.
I think maps are one widget where having a browser-/platform-level implementation has definite advantages. To be sure, depending on the browser to arrange geocoding is hazardous (I’d expect you’d get better results if you had to specify lat/long and could merely give a label to that point), and for that reason a consistent geocoding implementation as seen in a web component is good; but for the actual map rendering at least, fitting in with the platform would be good. For example, my user agent may know where I live and thus show me this place relative to that place—the sort of thing that a web component can’t possibly do.
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.
> For example, my user agent may know where I live and thus show me this place relative to that place—the sort of thing that a web component can’t possibly do.
I didn’t say where I am, I said where I live. I didn’t make the distinction clear enough, but I did mean it. The user agent may know more things that are able to make the map more useful for me.
> 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.
'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.
> I sometimes think that JavaScript developers would like to just get rid of HTML entirely
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.
I may be being naive, but how is that different than including Google Maps JS lib on your page? I assume that component is just a wrapper around the GMaps JS lib?
It allows you to use the <good-maps> element in your markup, rather than <div class="map">. Tbf, it would be more of an advantage if it used a better name than 'good-map'.
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.
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/
The proposal was not accepted, but .aero and .museum were, and we all now how those have since utterly revolutionized the internet.
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?
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.
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!
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....
I may be being naive, but how is that different than including Google Maps JS lib on your page? I assume that component is just a wrapper around the GMaps JS lib?
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.
> 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.
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.
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.
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.
> 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.
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.
The parent comment was suggesting it's possible to have a map element built in to the browser which would not leak the user's location. That is probably not possible.
> People don't have built-in mapping software installed on their computers.
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.
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.
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
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.
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.
I thought the author might have meant not disclosing your location to third-party websites, but disclosing it to Google, for example. Presumably you'd be able to customise your map provider and have a consistent experience, which is one advantage of this approach.
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.
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?
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".
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.
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.
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.
Not the author, but let's address your questions:
"Is this serious?"
It doesn't appear to be a joke
"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.
> 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.
> this is a highly interactive piece of content, with a metric shitload of complexity behind it
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.
Are you suggesting that playing a media file with all the different formats, streaming resolutions, etc is not a "metric shitload of complexity"?
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.
Example: https://www.webcomponents.org/element/keanulee/good-map