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 exten

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?