Ursprungstest für ein neues HTML-Element <permission>

Thomas Steiner

Es gibt eine Reihe von imperativen Methoden, um die Berechtigung zur Verwendung leistungsstarker Funktionen wie den Standortzugriff 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 im Ursprungstest von Chrome 126 und wir hoffen, es letztendlich standardisieren zu können.

Imperative Methoden zum Anfordern einer Berechtigung

Wenn Web-Apps Zugriff auf leistungsstarke Funktionen benötigen, müssen sie um Erlaubnis bitten. Wenn Google Maps beispielsweise den Standort des Nutzers mithilfe der Geolocation API benötigt, wird der Nutzer vom Browser gefragt, oft mit der Option, 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

Früher konnten Websites Methoden wie navigator.mediaDevices.getUserMedia() oder Notification.requestPermission() aufrufen, aber auch navigator.geolocation.getCurrentPosition(), sobald eine Website geladen wurde. 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 Berechtigungsspam verlangten Browseranbieter eine Nutzergeste wie das Klicken auf eine Schaltfläche oder ein Keydown-Ereignis, bevor eine Berechtigungsaufforderung angezeigt wurde. 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

Schließlich ist es für die Nutzenden zu einfach, selbst in eine Sackgasse zu gelangen. 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. Im schlimmsten Fall ist bei beiden Optionen eine vollständige Aktualisierung der Seite erforderlich, 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 die Berechtigung bitten, vorerst nur einen Teil der leistungsstarken Funktionen von Websites zu nutzen. 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 Attribut type

Das Attribut type enthält eine durch Leerzeichen getrennte Liste von Berechtigungen, die Sie anfordern. 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 verschiedene Phasen durchlaufen:

• 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 er zuvor eine Funktion nicht mehr zugelassen hat, kann er sie entweder weiterhin nicht zulassen oder diesmal erlauben.

  

Der Text des <permission>-Elements wird automatisch anhand des Status aktualisiert. Wenn beispielsweise die Berechtigung zur Verwendung einer Funktion erteilt wurde, ändert sich der Text, um zu signalisieren, dass das Element zugelassen ist. 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 Einschränkungen beim Styling für Ihren Anwendungsfall nicht funktionieren, teilen Sie uns gern mit, wie und warum das der Fall ist. Zwar können nicht alle Stilanforderungen erfüllt werden, wir hoffen aber, dass wir nach dem Ursprungstest möglichst sichere Möglichkeiten finden, um das <permission>-Element weiter gestalten zu können. 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 festgestellten Verstoß.

Die folgenden CSS-Eigenschaften können wie gewohnt verwendet werden:

• font-kerning
• font-optical-sizing
• font-stretch
• font-synthesis-weight
• font-synthesis-style
• font-synthesis-small-caps
• font-feature-settings
• forced-color-adjust
• text-rendering
• align-self
• anchor-name aspect-ratio
• border (und alle border-*-Properties)
• clear
• color-scheme
• contain
• contain-intrinsic-width
• contain-intrinsic-height
• container-name
• container-type
• counter-*
• flex-*
• float
• height
• isolation
• justify-self
• left
• order
• orphans
• outline-* (mit der zuvor für outline-offset notierten Ausnahme)
• overflow-anchor
• overscroll-behavior-*
• page
• position
• position-anchor
• content-visibility
• right
• scroll-margin-*
• scroll-padding-*
• text-spacing-trim
• top
• visibility
• x
• y
• ruby-position
• user-select
• width
• will-change
• z-index

Darüber hinaus können alle logisch äquivalenten Attribute verwendet werden (z. B. ist inline-size gleichbedeutend mit width), wobei dieselben Regeln wie ihre Äquivalente beachtet werden.

Pseudoklassen

Es gibt zwei spezielle Pseudoklassen, mit denen das <permission>-Element je nach Status gestaltet werden kann:

• :granted: Die Pseudoklasse :granted ermöglicht spezielle Stile, wenn eine Berechtigung gewährt wurde.
• :invalid: Die Pseudoklasse :invalid ermöglicht spezielle Stile, wenn sich das Element in einem ungültigen Zustand befindet, z. B. wenn es in einem ursprungsübergreifenden iFrame bereitgestellt 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. Eine Anleitung dazu, wie Sie Ihre Website für die Verwendung von Ursprungstests vorbereiten, finden Sie unter Erste Schritte mit Ursprungstests. 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 Repository 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 ist, wenn das <permission>-Element von anderen Browsern nicht unterstützt wird? 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 die öffentlichen Sitzungsnotizen lesen. Das Chrome-Team hat außerdem von beiden Anbietern formelle Standardpositionen angefordert (siehe 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, beschreibe das Problem bitte kurz.

Weitere Informationen

• Erklärung
• Position von WebKit-Standards
• Position von Mozilla-Standards

Danksagungen

Dieses Dokument wurde von Balázs Engedy, Thomas Nguyen, Penelope McLachlan, Marian Harbach, David Warren und Rachel Andrew geprüft.