Live data from Hacker News

Mapping in HTML – A Proposal for a New Element

shkspr.mobi

41–50 of 59 posts

Re: Mapping in HTML – A Proposal for a New Element

#41

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

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

Re: Mapping in HTML – A Proposal for a New Element

#42
post #38

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…

> 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?

Re: Mapping in HTML – A Proposal for a New Element

#43
post #30

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

That's going to get messy real quick when someone/something develops Planet-As-A-Service.

When you can delete a planet and fire up a fresh instance quickly, lat/long might get tricky.

Re: Mapping in HTML – A Proposal for a New Element

#44
post #42
post #38

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…

> 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…

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.

Re: Mapping in HTML – A Proposal for a New Element

#47

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

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.

Re: Mapping in HTML – A Proposal for a New Element

#49
post #42

Earlier quoted context omitted.

> 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…

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 c…

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

Re: Mapping in HTML – A Proposal for a New Element

#50
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.

Post reply on HN