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

Am 27.–28. April 2026 findet die beyond tellerrand Düsseldorf 2026 statt – zwei Tage Inspiration für Kreative und Entwickler:innen in Düsseldorf. Tickets kosten 349 €.

Alle Infos gibt’s auf beyondtellerrand.com

Praktischer Hinweis: „Holiday Inn Express“ oder „Holiday Inn – the niu, Tab“ direkt an der Venue buchen und abends noch mit Speakern und Community an der Bar abhängen. Wir freuen uns, wenn wir uns dort sehen!

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.

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