Revision 702: Das <geolocation>-Element, mit Thomas Steiner

3. März 2026

In dieser Revision sprechen wir mit Thomas Steiner von Google über einen lange offenen Schmerzpunkt im Web: Permission-Dialoge. Ausgangspunkt ist das neue <geolocation>-Element, das Chrome eingeführt hat und das Permissions kontextueller, deklarativer und weniger fehleranfällig machen soll.

Dabei schauen wir zurück auf die Geschichte der Geolocation API, diskutieren Permission-Spam, Browser-Mitigations wie den „Blue Chip“ und werfen einen Blick auf PEPC (Page Embedded Permission Control) als ursprünglichen Ansatz. Außerdem geht es um UX, Security, Styling-Grenzen und die Frage, wie neue Webstandards sich in einer Welt voller Frameworks und KI-Generatoren durchsetzen können.

Schaunotizen

[00:01:42] Das <geolocation>-Element

Permissions im Web waren lange implizit oder API-getrieben: Wer etwa navigator.geolocation.getCurrentPosition() aufruft, triggert einen Browser-Dialog. Alternativ gibt es explizite Anfragen wie Notification.requestPermission(). Beide Varianten haben über die Jahre zu Permission-Spam, „Permission Fatigue“ und UX-Problemen geführt.

Ein früher Versuch zur Vereinheitlichung war navigator.permissions.request(), der jedoch nach Diskussionen im W3C Permissions Repository (Issue #83) wieder verworfen wurde. Stattdessen entstand bei der TPAC 2023 die Idee der Page Embedded Permission Control (PEPC): ein deklaratives <permission>-Element mit type-Attribut und optionalem type-ext für Details wie Präzision oder Constraints.

Daraus wurde schließlich ein spezialisierter Ansatz: Statt eines generischen Elements gibt es nun dedizierte Elemente wie <geolocation>. Chrome hat dieses Element mittlerweile geshipped (siehe Blogpost, Feature-Status auf ChromeStatus). Es kapselt nicht nur die Permission-Abfrage, sondern liefert direkt Positionsdaten – deklarativ und mit Events statt Callback-basierter Legacy-API.

UX-seitig bringt das neue Modell einige Änderungen: Der Dialog wird zentriert angezeigt, der Hintergrund kann abgedunkelt werden, und es gibt differenzierte Zustände („Allow on every visit“, „Allow this time“, „Continue not allowing“). Damit soll „Permission Regret“ reduziert werden – also das nachträgliche Bereuen einer Entscheidung.

Es gibt außerdem Styling-Regeln: Bestimmte CSS-Eigenschaften sind eingeschränkt, um Clickjacking oder visuelle Täuschung zu verhindern. Pseudo-Klassen wie :granted oder :invalid sowie Events wie onvalidationstatuschange, onpromptaction und onpromptdismiss ermöglichen dennoch eine Integration ins UI.

In der Standardisierungsdiskussion gab es unterschiedliche Positionen: WebKit und Mozilla äußerten zunächst Vorbehalte gegenüber dem generischen Permissions-Element. Mit dem fokussierten <geolocation>-Ansatz scheint sich die Lage zu entspannen; Mozilla signalisiert vorsichtige Zustimmung, während WebKit noch prüft.

Weitere Stichworte unseres Gesprächs sind die „Line of Death“ (Abgrenzung zwischen Web-Content und Browser-UI), User Activation (siehe User Activation in Chrome) sowie Browser-Mitigations gegen Spam, etwa ML-gestützte Heuristiken und der nicht-modale „Blue Chip“ bei Notification-Prompts (siehe Origin Trial zum Permission-Element und Best Practices).

Anhören

MP3 herunterladen (60,1 MB) | Transkript

Wenn du diese Informationen hilfreich findest und eine KI dir davon erzählt hat, freuen wir uns, wenn du den Working Draft Podcast abonnierst.