Es gibt eine Reihe von imperativen Methoden, um die Erlaubnis zur Nutzung leistungsstarker Funktionen wie des Standortzugriffs in Webanwendungen einzuholen. Diese Methoden bergen jedoch einige Herausforderungen. Deshalb testet das Chrome-Berechtigungsteam eine neue deklarative Methode: ein spezielles HTML-<permission>-Element. Dieses Element befindet sich seit Chrome 126 in einem Ursprungstest. Wir hoffen, es letztendlich zu standardisieren.
Imperative Methoden zum Anfordern einer Berechtigung
Wenn Web-Apps Zugriff auf leistungsstarke Funktionen benötigen, müssen sie um Erlaubnis bitten. Wenn beispielsweise Google Maps den Standort des Nutzers über die Geolocation API benötigt, werden Nutzer in Browsern häufig aufgefordert, diese Entscheidung zu speichern. Dies ist ein gut definiertes Konzept in der Berechtigungsspezifikation.
Implizit bei der ersten Verwendung fragen oder explizit vorab anfordern
Die Geolocation API ist eine leistungsstarke API und basiert auf dem Ansatz der impliziten Anfrage bei der ersten Verwendung. Wenn eine App beispielsweise die Methode navigator.geolocation.getCurrentPosition() aufruft, wird die Berechtigungsanfrage beim ersten Aufruf automatisch angezeigt.
Ein weiteres Beispiel ist navigator.mediaDevices.getUserMedia().
Andere APIs wie die Notification API oder die Device Orientation and Motion API bieten in der Regel eine explizite Möglichkeit, die Berechtigung über eine statische Methode wie Notification.requestPermission() oder DeviceMotionEvent.requestPermission() anzufordern.
Herausforderungen bei imperativen Methoden zur Erläuterung von Berechtigungen
Berechtigungsspam
Bisher konnten Websites Methoden wie navigator.mediaDevices.getUserMedia() oder Notification.requestPermission(), aber auch navigator.geolocation.getCurrentPosition() sofort beim Laden einer Website aufrufen. Es wird eine Berechtigungsanfrage angezeigt, bevor der Nutzer mit der Website interagiert hat. Dies wird manchmal als Berechtigungsspam bezeichnet und betrifft beide Ansätze: die implizite Anfrage bei der ersten Verwendung und die explizite Anfrage im Voraus.
Browser-Maßnahmen und Anforderungen an Nutzergesten
Aufgrund von Berechtigungspam haben Browseranbieter eine Nutzeraktion wie einen Klick auf eine Schaltfläche oder ein Tastendruckereignis vor der Anzeige einer Berechtigungsanfrage eingeführt. Das Problem bei diesem Ansatz ist, dass es für den Browser sehr schwierig, wenn nicht unmöglich ist, herauszufinden, ob eine bestimmte Nutzergeste dazu führen sollte, dass ein Berechtigungsaufforderung angezeigt wird oder nicht. Vielleicht hat der Nutzer aus Frustration einfach irgendwo auf der Seite geklickt, weil das Laden der Seite so lange gedauert hat, oder er hat tatsächlich auf die Schaltfläche Meinen Standort ermitteln geklickt. Einige Websites haben es auch geschafft, Nutzer dazu zu bringen, auf Inhalte zu klicken, um den Prompt auszulösen.
Eine weitere Maßnahme besteht darin, Maßnahmen zum Schutz vor Missbrauch von Aufforderungen hinzuzufügen, z. B. Funktionen von vornherein vollständig zu blockieren oder die Berechtigungsanfrage nicht modal und weniger aufdringlich anzuzeigen.
Kontextualisierung von Berechtigungen
Eine weitere Herausforderung, insbesondere auf großen Bildschirmen, ist die Art und Weise, wie die Berechtigungsanfrage normalerweise angezeigt wird: über der Todeslinie, also außerhalb des Bereichs des Browserfensters, auf den die App zeichnen kann. Es kommt nicht selten vor, dass Nutzer die Aufforderung oben im Browserfenster übersehen, wenn sie gerade auf eine Schaltfläche unten im Fenster geklickt haben. Dieses Problem wird oft durch Maßnahmen zur Spamminimierung in Browsern verstärkt.
Keine einfache Undo-Funktion
Außerdem ist es zu einfach, dass Nutzer in eine Sackgasse geraten. Wenn der Nutzer beispielsweise den Zugriff auf eine Funktion blockiert hat, muss er wissen, dass er im Drop-down-Menü für Websiteinformationen entweder die Berechtigungen zurücksetzen oder die blockierten Berechtigungen wieder aktivieren kann. Bei beiden Optionen muss die Seite im schlimmsten Fall vollständig neu geladen werden, bis die aktualisierte Einstellung wirksam wird. Websites können Nutzern keine einfache Verknüpfung zum Ändern eines vorhandenen Berechtigungsstatus anbieten und müssen ihnen mühsam erklären, wie sie ihre Einstellungen ändern können, wie unten im folgenden Google Maps-Screenshot zu sehen.
Wenn die Berechtigung für die Nutzung der App entscheidend ist, z. B. der Mikrofonzugriff für eine Videokonferenzanwendung, werden in Apps wie Google Meet aufdringliche Dialogfelder angezeigt, in denen der Nutzer angewiesen wird, die Blockierung der Berechtigung aufzuheben.
Ein deklaratives <permission>-Element
Um die in diesem Beitrag beschriebenen Herausforderungen zu bewältigen, hat das Chrome-Berechtigungsteam einen Ursprungstest für ein neues HTML-Element namens <permission> gestartet. Mit diesem Element können Entwickler deklarativ um Erlaubnis bitten, eine Teilmenge der leistungsstarken Funktionen zu verwenden, die für Websites verfügbar sind. In der einfachsten Form verwenden Sie es wie im folgenden Beispiel:
<permission type="camera" />
Es wird noch aktiv diskutiert, ob <permission> ein Nullelement sein sollte oder nicht. Ein Void-Element ist ein selbstschließendes Element in HTML, das keine untergeordneten Knoten haben kann. Das bedeutet, dass es in HTML kein End-Tag haben darf.
Das type-Attribut
Das Attribut type enthält eine durch Leerzeichen getrennte Liste der angeforderten Berechtigungen. Zum Zeitpunkt der Erstellung dieses Artikels sind die zulässigen Werte 'camera', 'microphone' und camera microphone (durch ein Leerzeichen getrennt). Dieses Element wird standardmäßig ähnlich wie Schaltflächen mit einem einfachen User-Agent-Styling gerendert.
Das type-ext-Attribut
Für einige Berechtigungen, für die zusätzliche Parameter zulässig sind, können im Attribut type-ext durch Leerzeichen getrennte Schlüssel/Wert-Paare angegeben werden, z. B. precise:true für die Berechtigung zur Standortermittlung.
Das lang-Attribut
Der Schaltflächentext wird vom Browser bereitgestellt und soll einheitlich sein. Er kann daher nicht direkt angepasst werden. Der Browser ändert die Sprache des Texts basierend auf der übernommenen Sprache des Dokuments oder der übergeordneten Elementkette oder einem optionalen lang-Attribut. Das bedeutet, dass Entwickler das <permission>-Element nicht selbst lokalisieren müssen. Wenn das <permission>-Element die Testphase des Ursprungs überschreitet, können für jeden Berechtigungstyp mehrere Strings oder Symbole unterstützt werden, um die Flexibilität zu erhöhen. Wenn du das Element <permission> verwenden möchtest und einen bestimmten String oder ein bestimmtes Symbol benötigst, wende dich bitte an uns.
Verhalten
Wenn der Nutzer mit dem Element <permission> interagiert, kann er durch verschiedene Phasen schalten:
Wenn der Nutzer eine Funktion noch nicht erlaubt hat, kann er sie für jeden Besuch oder nur für den aktuellen Besuch erlauben.
Wenn die Funktion zuvor zugelassen wurde, kann sie weiterhin zugelassen oder deaktiviert werden.
Wenn eine Funktion zuvor abgelehnt wurde, kann sie weiterhin abgelehnt oder dieses Mal genehmigt werden.
Der Text des <permission>-Elements wird automatisch anhand des Status aktualisiert. Wenn beispielsweise die Berechtigung zur Verwendung einer Funktion gewährt wurde, wird der Text in „Zugelassen“ geändert. Wenn die Berechtigung zuerst erteilt werden muss, ändert sich der Text und der Nutzer wird aufgefordert, die Funktion zu verwenden. Vergleichen Sie den vorherigen Screenshot mit dem folgenden, um die beiden Status zu sehen.
CSS-Design
Damit Nutzer die Schaltfläche leicht als Oberfläche zum Zugriff auf leistungsstarke Funktionen erkennen können, ist das Styling des <permission>-Elements eingeschränkt. Wenn die Stilvorgaben für Ihren Anwendungsfall nicht geeignet sind, teilen Sie uns gern mit, warum das so ist. Auch wenn nicht alle Anforderungen an das Styling erfüllt werden können, hoffen wir, nach dem Ursprungstest sichere Möglichkeiten zu finden, das <permission>-Element noch besser zu stylen. In der folgenden Tabelle sind einige Properties aufgeführt, für die Einschränkungen oder spezielle Regeln gelten. Wenn eine der Regeln verletzt wird, wird das Element <permission> deaktiviert und kann nicht mehr verwendet werden. Alle Versuche, mit ihm zu interagieren, führen zu Ausnahmen, die mit JavaScript abgefangen werden können. Die Fehlermeldung enthält weitere Details zum erkannten Verstoß.
| Attribut | Regeln |
|---|---|
|
Damit können Sie die Text- und Hintergrundfarbe festlegen. Der Kontrast zwischen den beiden Farben muss für gut lesbaren Text ausreichen (Kontrastverhältnis von mindestens 3). Der Alphakanal muss 1 sein. |
|
Muss zwischen small und xxxlarge liegen. Andernfalls wird das Element deaktiviert. Der Zoom wird bei der Berechnung von font-size berücksichtigt. |
|
Negative Werte werden auf 0 korrigiert. |
margin (alle) |
Negative Werte werden auf 0 korrigiert. |
|
Werte unter 200 werden auf 200 korrigiert. |
|
Werte, die nicht normal oder italic sind, werden auf normal korrigiert. |
|
Werte über 0.5em werden auf 0.5em korrigiert. Werte unter 0 werden auf 0 korrigiert. |
|
Werte, die nicht inline-block oder none sind, werden auf inline-block korrigiert. |
|
Werte über 0.2em werden auf 0.2em korrigiert. Werte unter -0.05em werden auf -0.05em korrigiert. |
|
Der Standardwert ist 1em. Falls angegeben, wird der höchste berechnete Wert zwischen dem Standardwert und den angegebenen Werten berücksichtigt. |
|
Der Standardwert ist 3em. Wenn angegeben, wird der niedrigste berechnete Wert zwischen dem Standardwert und den angegebenen Werten berücksichtigt. |
|
Der Standardwert ist fit-content. Falls angegeben, wird der maximale berechnete Wert zwischen dem Standardwert und den angegebenen Werten berücksichtigt. |
|
Der Standardwert ist dreimal fit-content. Wenn ein Wert angegeben wird, wird der niedrigste berechnete Wert zwischen dem Standardwert und dem angegebenen Wert berücksichtigt. |
|
Wird nur wirksam, wenn height auf auto gesetzt ist. In diesem Fall werden Werte über 1em auf 1em korrigiert und padding-bottom wird auf den Wert padding-top gesetzt. |
|
Wird nur wirksam, wenn width auf auto gesetzt ist. In diesem Fall werden Werte über 5em auf 5em korrigiert und padding-right auf den Wert padding-left. gesetzt. |
|
Verzerrende visuelle Effekte sind nicht zulässig. Derzeit akzeptieren wir nur 2D-Übersetzungen und proportionales Upscaling. |
Die folgenden CSS-Eigenschaften können wie gewohnt verwendet werden:
font-kerningfont-optical-sizingfont-stretchfont-synthesis-weightfont-synthesis-stylefont-synthesis-small-capsfont-feature-settingsforced-color-adjusttext-renderingalign-selfanchor-name aspect-ratioborder(und alleborder-*-Properties)clearcolor-schemecontaincontain-intrinsic-widthcontain-intrinsic-heightcontainer-namecontainer-typecounter-*flex-*floatheightisolationjustify-selfleftorderorphansoutline-*(mit der oben füroutline-offseterwähnten Ausnahme)overflow-anchoroverscroll-behavior-*pagepositionposition-anchorcontent-visibilityrightscroll-margin-*scroll-padding-*text-spacing-trimtopvisibilityxyruby-positionuser-selectwidthwill-changez-index
Außerdem können alle logisch äquivalenten Properties verwendet werden (z. B. inline-size ist äquivalent zu width). Dabei gelten dieselben Regeln wie für die entsprechenden äquivalenten Properties.
Pseudoklassen
Es gibt zwei spezielle Pseudoklassen, mit denen das <permission>-Element je nach Status gestaltet werden kann:
:granted: Mit der Pseudoklasse:grantedkann ein spezielles Styling verwendet werden, wenn eine Berechtigung gewährt wurde.:invalid: Mit der Pseudoklasse:invalidkann ein spezielles Styling festgelegt werden, wenn sich das Element in einem ungültigen Zustand befindet, z. B. wenn es in einem iframe mit unterschiedlichen Ursprüngen gesendet wird.
permission {
background-color: green;
}
permission:granted {
background-color: light-green;
}
/* Not supported during the origin trial. */
permission:invalid {
background-color: gray;
}
JavaScript-Ereignisse
Das Element <permission> ist für die Verwendung mit der Permissions API vorgesehen.
Es gibt eine Reihe von Ereignissen, auf die gewartet werden kann:
onpromptdismiss: Dieses Ereignis wird ausgelöst, wenn der Nutzer die vom Element ausgelöste Berechtigungsanfrage geschlossen hat, z. B. durch Klicken auf die Schaltfläche „Schließen“ oder außerhalb der Aufforderung.onpromptaction: Dieses Ereignis wird ausgelöst, wenn die vom Element ausgelöste Berechtigungsanfrage durch eine Aktion des Nutzers auf die Aufforderung selbst geklärt wurde. Das bedeutet nicht unbedingt, dass sich der Berechtigungsstatus geändert hat. Der Nutzer hat möglicherweise eine Aktion ausgeführt, die den Status quo beibehält, z. B. eine Berechtigung weiterhin zugelassen.onvalidationstatuschange: Dieses Ereignis wird ausgelöst, wenn das Element von"valid"zu"invalid"wechselt. Das Element wird als"valid"eingestuft, wenn der Browser der Integrität des Signals vertraut, wenn der Nutzer darauf klickt, und als"invalid", wenn das nicht der Fall ist, z. B. wenn das Element teilweise von anderen HTML-Inhalten verdeckt wird.
Sie können Event-Listener für diese Ereignisse direkt inline im HTML-Code (<permission type="…" onpromptdismiss="alert('The prompt was dismissed');" />) oder mit addEventListener() für das <permission>-Element registrieren, wie im folgenden Beispiel gezeigt.
<permission type="camera" />
<script>
const permission = document.querySelector('permission');
permission.addEventListener('promptdismiss', showCameraWarning);
function showCameraWarning() {
// Show warning that the app isn't fully usable
// unless the camera permission is granted.
}
const permissionStatus = await navigator.permissions.query({name: "camera"});
permissionStatus.addEventListener('change', () => {
// Run the check when the status changes.
if (permissionStatus.state === "granted") {
useCamera();
}
});
// Run the initial check.
if (permissionStatus.state === "granted") {
useCamera();
}
</script>
Funktionserkennung
Wenn ein Browser ein HTML-Element nicht unterstützt, wird es nicht angezeigt. Wenn Sie das <permission>-Element in Ihrem HTML-Code haben, passiert also nichts, wenn der Browser es nicht kennt. Sie können die Unterstützung weiterhin mit JavaScript erkennen, z. B. um einen Berechtigungsaufforderung zu erstellen, die durch einen Klick auf eine normale <button> ausgelöst wird.
if ('HTMLPermissionElement' in window) {
// The `<permission>` element is supported.
}
Ursprungstest
Wenn Sie das <permission>-Element auf Ihrer Website mit echten Nutzern testen möchten, registrieren Sie sich für den Origin-Test.
In Erste Schritte mit Ursprungstests erfahren Sie, wie Sie Ihre Website für Ursprungstests vorbereiten. Der Ursprungstest läuft von Chrome 126 bis 131 (19. Februar 2025).
Demo
Sehen Sie sich die Demo und den Quellcode auf GitHub an. Hier ist ein Screenshot der Funktion in einem unterstützten Browser.
Feedback
Wir würden uns freuen, von Ihnen zu hören, wie <permission> für Ihren Anwendungsfall funktioniert. Sie können auf eines der Probleme im Repository antworten oder ein neues Problem melden. Über öffentliche Signale im repo für das Element <permission> informieren Sie uns und andere Browser darüber, dass Sie daran interessiert sind.
FAQ
- Inwiefern ist das besser als ein normaler
<button>, der mit der Berechtigungs-API gekoppelt ist? Ein Klick auf ein<button>ist eine Nutzergeste, aber Browser können nicht überprüfen, ob sie mit der Anfrage zur Berechtigungsanfrage verknüpft ist. Wenn der Nutzer auf eine<permission>geklickt hat, kann der Browser sicher sein, dass der Klick mit einer Berechtigungsanfrage zusammenhängt. So kann der Browser Abläufe ermöglichen, die sonst viel riskanter wären. So kann der Nutzer beispielsweise die Blockierung einer Berechtigung ganz einfach rückgängig machen. - Was passiert, wenn andere Browser das
<permission>-Element nicht unterstützen? Das<permission>-Element kann als progressive Verbesserung verwendet werden. In nicht unterstützten Browsern kann ein klassischer Berechtigungsablauf verwendet werden. Beispielsweise basierend auf dem Klick auf eine reguläre<button>. Das Berechtigungsteam arbeitet auch an einer Polyfill. Setze dem GitHub-Repository ein Sternchen, um benachrichtigt zu werden, sobald es verfügbar ist. - Wurde das mit anderen Browseranbietern besprochen? Das Element
<permission>wurde 2023 in einer Breakout-Sitzung auf der W3C TPAC aktiv diskutiert. Sie können sich die Notizen zur öffentlichen Sitzung ansehen. Das Chrome-Team hat außerdem von beiden Anbietern formale Stellungnahmen zu den Standards angefordert. Weitere Informationen finden Sie im Abschnitt Weitere Informationen. Das Element<permission>ist ein aktuelles Thema in Diskussionen mit anderen Browsern und wir hoffen, es zu standardisieren. - Sollte dies eigentlich ein Nullelement sein? Es wird noch aktiv diskutiert, ob
<permission>ein Nullelement sein sollte oder nicht. Wenn du Feedback hast, kannst du dich dazu äußern.
Weitere Informationen
Danksagungen
Dieses Dokument wurde von Balázs Engedy, Thomas Nguyen, Penelope McLachlan, Marian Harbach, David Warren und Rachel Andrew geprüft.