Das HTML-Element <geolocation>

Veröffentlicht am 13. Januar 2026

Ab Chrome 144 können Sie das neue HTML-Element <geolocation> verwenden. Dieses Element stellt eine große Veränderung bei der Art und Weise dar, wie Websites Nutzerstandortdaten anfordern. Es wird von skriptgesteuerten Berechtigungsaufforderungen zu einer deklarativen, nutzerorientierten Erfahrung übergegangen. Dadurch wird der Boilerplate-Code reduziert, der zum Verarbeiten von Berechtigungsstatus und Fehlern erforderlich ist. Außerdem wird das Signal der Nutzerabsicht verstärkt, wodurch Browser-Interventionen (z. B. stille Blöcke) vermieden werden.

Diese Einführung ist das Ergebnis umfangreicher Tests unter realen Bedingungen und intensiver Diskussionen mit der Webstandards-Community. Um den Nutzen dieses Elements zu verstehen, ist es wichtig, die Geschichte seiner Entwicklung und die Daten zu untersuchen, die sein Design beeinflusst haben.

Von der generischen <permission> zur spezifischen <geolocation>

Das <geolocation>-Element ist die neueste Entwicklung der Initiative zur Berechtigungssteuerung auf der Seite, bei der es ursprünglich als generisches <permission>-Element mit einem type-Attribut vorgeschlagen wurde (siehe Originalerklärungen). Der Wert des Attributs „type“ (z. B. "geolocation") bestimmt den Typ der angeforderten Berechtigung. Der erste Vorschlag enthält beispielsweise Werte wie Kamera, Mikrofon und Geolocation.

Konzeptvalidierung

Wir haben von Chrome 126 bis Chrome 143 einen Ursprungstest für das generische <permission>-Element durchgeführt. Ziel dieses Tests war es, die Hypothese zu prüfen, dass eine spezielle, kontextbezogene Schaltfläche das Vertrauen der Nutzer und die Entscheidungsfindung verbessern würde.

Die Ergebnisse dieses Ursprungstests haben die Validierung dieses Kernkonzepts unterstützt:

  • Zoom meldete einen Rückgang der Fehler bei der Aufnahme von Kamera- oder Mikrofonsignalen (z. B. Blocker auf Systemebene) um 46,9 %, da das Element verwendet wurde, um Nutzer durch die Wiederherstellung zu führen.
  • Immobiliare.it verzeichnete einen Anstieg von 20% bei erfolgreichen Geolocation-Abläufen.
  • ZapImóveis konnte eine Erfolgsrate von 54,4% bei Nutzern beobachten, die sich aus dem Status „zuvor blockiert“ erholten, als ihnen das Element präsentiert wurde.

Neudefinition des Designs

Das Konzept erwies sich zwar als erfolgreich, die Implementierung musste jedoch verfeinert werden. Das Feedback von Browseranbietern, darunter Apple (Safari/WebKit) und Mozilla (Firefox), deutete darauf hin, dass ein „universelles“ Element erhebliche Komplexität in Bezug auf das Verhalten einzigartiger Funktionen mit sich bringt.

Daher sind wir von einer allgemeinen Berechtigungssteuerung zu gezielten, funktionsspezifischen Elementen übergegangen (siehe WICG-Diskussion). Das <geolocation>-Element ist das erste dieser speziellen Steuerelemente, das eingeführt wird. Außerdem entwickeln wir ein eigenes <usermedia>-Element (für den Kamera- und Mikrofonzugriff), das ein eigenes Origin-Trial hat.

Im Gegensatz zum ursprünglichen Vorschlag, der sich auf die Verwaltung des Berechtigungsstatus (d. h. „Zulassen“ oder „Ablehnen“) konzentrierte, fungieren diese neuen Elemente als Datenvermittler. In den meisten Anwendungsfällen ist es daher nicht mehr erforderlich, die JavaScript-APIs direkt aufzurufen.

In dieser Tabelle werden die Unterschiede zwischen der Geolocation JavaScript API, dem <permission>-Element und dem neuen <geolocation>-Element beschrieben.
Feature Geolocation JS API HTML-Element -HTML-Element
Auslösendes Ereignis für Berechtigungsaufforderung Ausführung von imperativen Scripts (getCurrentPosition) Der Nutzer klickt auf das vom Browser gesteuerte -Element. Der Nutzer klickt auf das vom Browser gesteuerte -Element.
Browserrolle Prompt basierend auf dem Status festlegen Fungiert als Berechtigungsvermittler Als Datenvermittler fungieren
Verantwortung für die Website JavaScript API manuell aufrufen, Callbacks verarbeiten und Berechtigungsfehler beheben geolocation API implementieren, sobald die Berechtigung erteilt wurde location-Ereignis anhören
Hauptziel Einfacher Standortzugriff Berechtigungsanfrage Berechtigungsanfrage und Standortzugriff

Warum sollte das <geolocation>-Element verwendet werden?

Derzeit basieren Geolocation-Abläufe auf der Geolocation API. Dadurch werden Berechtigungsaufforderungen ausgelöst, die Nutzer unterbrechen können, wenn sie ohne Kontext oder sogar beim Laden der Seite ausgelöst werden. Die Verwendung dieser imperativen Prompts wird jedoch aufgrund von Browsereingriffen immer weniger praktikabel. Chrome blockiert beispielsweise aktiv Berechtigungsanfragen, wenn ein Nutzer die Aufforderung dreimal geschlossen hat. Dadurch wird eine temporäre stille Blockierung erzwungen, die anfangs eine Woche lang dauert. Das bedeutet, dass Legacy-Code, der versucht, eine Aufforderung auszulösen, möglicherweise im Hintergrund fehlschlägt. Der Nutzer kann die Funktion dann nicht nutzen und hat keine Möglichkeit, sie zu aktivieren. Außerdem fehlt es Standardprompts oft an Kontext. Wenn ein Prompt unerwartet angezeigt wird, blockieren Nutzer ihn möglicherweise reflexartig oder versehentlich, ohne zu wissen, dass diese Entscheidung zu einer dauerhaften Blockierung führt, die nur schwer rückgängig gemacht werden kann. Diese Kontextlücke – und nicht die Funktion selbst – ist ein Hauptgrund für die hohe Ablehnungsrate.

Das <geolocation>-Element löst das Problem der Kontextlücke, indem sichergestellt wird, dass Anfragen ausschließlich vom Nutzer initiiert werden. Dieses Modell bietet drei wesentliche Vorteile:

  • Klare Intention und klares Timing:Wenn der Nutzer auf die Schaltfläche Standort verwenden klickt, signalisiert er explizit, dass er seinen Standort in diesem Moment verwenden möchte. Das zeigt, dass sie den Wert der Standortfreigabe verstehen und sie aktiv nutzen möchten. So wird aus einer potenziellen Blockierung eine erfolgreiche Interaktion.
  • Vereinfachte Wiederherstellung:Wenn ein Nutzer den Standortzugriff beim Aufrufen einer Website zuvor blockiert hat (vielleicht versehentlich oder aufgrund fehlenden Kontexts), wird durch Klicken auf das Element ein spezieller Wiederherstellungsprozess ausgelöst. So können sie den Standortzugriff wieder aktivieren, wenn sie ihn tatsächlich verwenden möchten, ohne sich durch die Website-Einstellungen des Browsers klicken zu müssen.
  • Automatische Aktualisierung:Wenn die Berechtigung bereits erteilt wurde, wird durch Klicken auf das Element sofort eine Aktualisierung ausgelöst und neue Daten werden abgerufen, ohne dass der Nutzer noch einmal aufgefordert wird.

Implementierung

Die Einbindung des Elements erfordert deutlich weniger Boilerplate-Code als die JavaScript API. Anstatt Callbacks und Fehlerstatus manuell zu verwalten, können Entwickler das Tag auf der Seite einfügen und auf das onlocation-Ereignis warten.

<geolocation
  onlocation="handleLocation(event)"
  autolocate
  accuracymode="precise">
</geolocation>
function handleLocation(event) {
  // Directly access the GeolocationPosition object on the element
  if (event.target.position) {
    const { latitude, longitude } = event.target.position.coords;
    console.log("Location retrieved:", latitude, longitude);
  } else if (event.target.error) {
    console.error("Error:", event.target.error.message);
  }
}

Wichtige Attribute und Eigenschaften

  • autolocate: Der Standort wird automatisch abgerufen, wenn das Element geladen wird. Dies erfolgt jedoch nur, wenn der aktuelle Berechtigungsstatus dies bereits zulässt, um unerwartete Aufforderungen zu vermeiden.
  • accuracymode: Akzeptiert den Wert "precise" oder "approximate", der der Standardoption enableHighAccuracy entspricht.
  • watch: Das Verhalten wird an watchPosition() angepasst und Ereignisse werden kontinuierlich ausgelöst, während sich der Nutzer bewegt.
  • position: Eine schreibgeschützte Property für das DOM-Element, die das GeolocationPosition-Objekt zurückgibt, sobald es verfügbar ist.
  • error: Eine schreibgeschützte Property, die bei einem fehlgeschlagenen Request ein GeolocationPositionError zurückgibt.
Die Demo, die in der Bildunterschrift verlinkt ist, enthält Schaltflächen zum Testen der drei Konfigurationstypen.
Das <geolocation>-Element-Demo zeigt die drei Hauptkonfigurationen: „Manuelle Anfrage“, „Automatische Anfrage“ (mit „autolocate“) und „Standort beobachten“ (mit „watch“). Sie können diese Verhaltensweisen auf der Live-Demoseite testen.

Stileinschränkungen

Um das Vertrauen der Nutzer zu stärken und irreführende Designmuster zu verhindern, gelten für das <geolocation>-Element bestimmte Formatierungsbeschränkungen, die denen des früheren <permission>-Elementtests ähneln. Sie können die Schaltfläche an das Design der Website anpassen. Der Browser erzwingt jedoch einige Einschränkungen:

  • Lesbarkeit:Text- und Hintergrundfarben werden auf ausreichenden Kontrast (in der Regel ein Verhältnis von mindestens 3:1) geprüft, damit die Berechtigungsanfrage immer lesbar ist. Außerdem muss der Alphakanal (Deckkraft) auf 1 gesetzt werden, damit das Element nicht täuschend transparent ist.
  • Größe und Abstand:Das Element erzwingt Mindest- und Höchstwerte für Breite, Höhe und Schriftgröße. Negative Ränder oder Umriss-Offsets sind deaktiviert, um zu verhindern, dass das Element visuell verdeckt wird oder andere Inhalte auf irreführende Weise überlappt.
  • Visuelle Integrität:Verzerrungseffekte sind begrenzt. Die Transformation unterstützt beispielsweise nur 2D-Verschiebungen und proportionale Skalierung.
  • CSS-Pseudoklassen:Das Element unterstützt statusbasiertes Styling, z. B. „:granted“ (wenn die Berechtigung aktiv ist).

Strategie für Progressive Enhancement

Die Standardisierung neuer HTML-Elemente ist ein schrittweiser Prozess. Entwickler können das <geolocation>-Element jedoch schon heute verwenden, ohne die Kompatibilität für Nutzer anderer Browser zu beeinträchtigen.

Das Element ist so konzipiert, dass es bei Bedarf reibungslos herabgesetzt werden kann. Browser, die das <geolocation>-Element nicht unterstützen, behandeln es als [HTMLUnknownElement](https://developer.mozilla.org/docs/Web/API/HTMLUnknownElement). Wichtig: Wenn der Browser das Element unterstützt, werden die untergeordneten Elemente nicht gerendert. So kann das HTML sowohl für unterstützte als auch für nicht unterstützte Browser sauber geschrieben werden.

Benutzerdefiniertes Fallback-Muster

Wenn Sie die Fallback-Funktion selbst steuern möchten, können Sie untergeordnete Elemente wie eine Schaltfläche verwenden, die Sie mit der regulären JavaScript Geolocation API verknüpfen.

<geolocation onlocation="updateMap()">
  <!-- Fallback contents if the element is not supported -->
  <button onclick="navigator.geolocation.getCurrentPosition(updateMap)">
    Use my location
  </button>
</geolocation>

Polyfill

Alternativ können Sie ein Polyfill von npm installieren, das alle Vorkommen von <geolocation> transparent und automatisch durch ein benutzerdefiniertes Element <geo-location> (mit Bindestrich) ersetzt, das auf der regulären JavaScript Geolocation API basiert. Wenn der Browser das <geolocation>-Element unterstützt, führt das Polyfill nichts aus. In dieser Demo sehen Sie das Polyfill in Aktion. Der Quellcode ist auf GitHub verfügbar.

if (!('HTMLGeolocationElement' in window)) {
  await import('https://unpkg.com/geolocation-element-polyfill/index.js');
}
<geolocation onlocation="updateMap()"></geolocation>

Funktionserkennung

Bei komplexerer Logik können Sie die Unterstützung programmatisch über die Schnittstelle erkennen:

if ('HTMLGeolocationElement' in window) {
  // Use modern <geolocation> element logic
} else {
  // Fallback to legacy navigator.geolocation API
}

Zusammenfassung

Wir sind gespannt, wie Entwickler mit dem neuen <geolocation>-HTML-Element leistungsfähigere Szenarien für erneute Standortversuche implementieren werden. Es handelt sich um eine Verlagerung hin zu funktionsspezifischen Elementen, die darauf zugeschnitten sind, wie Nutzer das Web heute tatsächlich verwenden.

Für andere Anwendungsfälle für Berechtigungen können Sie ab Chrome 144 am Ursprungstest für das <usermedia>-HTML-Element teilnehmen, wodurch die gleichen ergonomischen Vorteile für Kamera und Mikrofon erzielt werden.

Danksagungen

Dieses Dokument wurde von Andy Paicu, Gilberto Cocchi und Rachel Andrew geprüft.