31–40 of 59 posts
Oh come on! We've gotten ourselves into messes like this before, please have the foresight to add a "planet" attribute.
(No, not kidding.)
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.…
Earlier quoted context omitted.
Presumably by dynamically adding (and styling) markers.
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.
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
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.
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?
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.…
> How about we get rid of all those external libraries as a dependency? Let's do what we did with and make mapping a first class element. The difference is that you really can't do very well without . 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…
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
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 a…
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 .
- 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.
Earlier quoted context omitted.
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 a…
> 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. 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 .