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