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

Thomas Steiner

Es gibt eine Reihe von zwingenden Methoden, um die Berechtigung zur Nutzung leistungsstarker Funktionen wie des Standortzugriffs in Web-Apps anzufordern. Diese Methoden sind mit einer Reihe von Herausforderungen verbunden. Das Chrome-Berechtigungsteam testet daher eine neue deklarative Methode: ein spezielles HTML-<permission>-Element. Dieses Element befindet sich seit Chrome 126 in der Ursprungstestphase. Wir hoffen, es letztendlich standardisieren zu können.

Imperative Methoden zum Anfordern von Berechtigungen

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 oft aufgefordert, eine Entscheidung zu treffen, die gespeichert werden kann. Dies ist ein wohl definiertes Konzept in der Berechtigungsspezifikation.

Implizite Aufforderung bei der ersten Verwendung im Vergleich zur expliziten Aufforderung im Voraus

Die Geolocation API ist eine leistungsstarke API, die auf dem Ansatz „Implizite Anfrage bei der ersten Verwendung“ basiert. Wenn eine App beispielsweise die Methode navigator.geolocation.getCurrentPosition() aufruft, wird die Berechtigungsaufforderung beim ersten Aufruf automatisch eingeblendet. Ein weiteres Beispiel ist navigator.mediaDevices.getUserMedia().

Andere APIs wie die Notification API oder die Device Orientation and Motion API haben in der Regel eine explizite Möglichkeit, die Berechtigung über eine statische Methode wie Notification.requestPermission() oder DeviceMotionEvent.requestPermission() anzufordern.

Herausforderungen bei imperativen Methoden zum Einholen von Berechtigungen

Berechtigungs-Spam

Bisher konnten Websites Methoden wie navigator.mediaDevices.getUserMedia() oder Notification.requestPermission(), aber auch navigator.geolocation.getCurrentPosition() sofort beim Laden einer Website aufrufen. Ein Berechtigungs-Prompt wurde eingeblendet, bevor der Nutzer mit der Website interagiert hatte. Dies wird manchmal als Berechtigungs-Spam bezeichnet und betrifft beide Ansätze, sowohl die implizite Abfrage bei der ersten Verwendung als auch die explizite Anfrage im Voraus.

Browser-Maßnahmen und Anforderungen an Nutzergesten

Aufgrund von Berechtigungs-Spam müssen Browseranbieter eine Nutzeraktion wie einen Klick auf eine Schaltfläche oder ein Keydown-Ereignis verlangen, bevor eine Berechtigungsaufforderung angezeigt wird. Das Problem bei diesem Ansatz ist, dass es für den Browser sehr schwierig, wenn nicht unmöglich ist, herauszufinden, ob eine bestimmte Nutzeraktion zu einer Aufforderung zur Berechtigung führen sollte oder nicht. Vielleicht hat der Nutzer aus Frustration einfach irgendwo auf die Seite geklickt, weil das Laden so lange gedauert hat. Es kann aber auch sein, dass er tatsächlich auf die Schaltfläche Locate me (Standort ermitteln) geklickt hat. Einige Websites haben auch gelernt, Nutzer dazu zu bringen, auf Inhalte zu klicken, um den Prompt auszulösen.

Eine weitere Maßnahme ist das Hinzufügen von Maßnahmen zur Eindämmung von Prompt-Missbrauch, z. B. das vollständige Blockieren von Funktionen oder das Anzeigen des Berechtigungs-Prompts auf nicht modale, weniger aufdringliche Weise.

Kontextualisierung von Berechtigungen

Eine weitere Herausforderung, insbesondere auf großen Bildschirmen, ist die Art und Weise, wie die Berechtigungsaufforderung normalerweise angezeigt wird: oberhalb der Trennlinie, d. h. außerhalb des Bereichs des Browserfensters, in dem die App gerendert werden kann. Es kommt häufig vor, dass Nutzer den Hinweis oben im Browserfenster übersehen, wenn sie gerade auf eine Schaltfläche unten im Fenster geklickt haben. Dieses Problem wird oft durch Maßnahmen zur Spam-Abwehr im Browser verschärft.

Nicht einfach rückgängig zu machen

Schließlich ist es für Nutzer zu einfach, sich in einer Sackgasse zu verirren. Wenn ein Nutzer beispielsweise den Zugriff auf eine Funktion blockiert hat, muss er sich des Drop-down-Menüs mit den Websiteinformationen bewusst sein, in dem er entweder Berechtigungen zurücksetzen oder blockierte Berechtigungen wieder aktivieren kann. Bei beiden Optionen ist im schlimmsten Fall ein vollständiges Neuladen der Seite erforderlich, bis die aktualisierte Einstellung wirksam wird. Websites können Nutzern keine einfache Möglichkeit bieten, einen vorhandenen Berechtigungsstatus zu ändern. Sie müssen Nutzern mühsam erklären, wie sie ihre Einstellungen ändern können, wie im folgenden Google Maps-Screenshot unten zu sehen ist.

Wenn die Berechtigung für die Nutzung der App unerlässlich ist, z. B. der Mikrofonzugriff für eine Videokonferenzanwendung, zeigen Apps wie Google Meet aufdringliche Dialogfelder an, in denen der Nutzer aufgefordert wird, die Berechtigung zu entsperren.

Ein deklaratives <permission>-Element

Um die in diesem Beitrag beschriebenen Herausforderungen zu bewältigen, hat das Chrome-Berechtigungsteam einen Origin-Test für ein neues HTML-Element, <permission>, gestartet. Mit diesem Element können Entwickler deklarativ die Berechtigung anfordern, vorerst 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 leeres Element sein sollte oder nicht. Ein leeres Element ist ein selbstschließendes Element in HTML, das keine untergeordneten Knoten haben kann. In HTML bedeutet das, dass es kein End-Tag haben darf.

Das Attribut type

Das Attribut type enthält eine durch Leerzeichen getrennte Liste der Berechtigungen, die Sie anfordern. Zum Zeitpunkt der Erstellung dieses Dokuments sind die zulässigen Werte 'camera', 'microphone' und camera microphone (durch Leerzeichen getrennt). Dieses Element wird standardmäßig ähnlich wie Schaltflächen mit minimalem User-Agent-Styling gerendert.

Das Attribut type-ext

Für einige Berechtigungen, die zusätzliche Parameter zulassen, akzeptiert das Attribut type-ext durch Leerzeichen getrennte Schlüssel/Wert-Paare, z. B. precise:true für die Berechtigung für den geografischen Standort.

Das Attribut lang

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 geerbten Sprache des Dokuments oder der übergeordneten Elementkette oder einem optionalen lang-Attribut. Entwickler müssen das <permission>-Element also nicht selbst lokalisieren. Wenn das <permission>-Element über die Origin-Trial-Phase hinausgeht, werden möglicherweise mehrere Strings oder Symbole für jeden Berechtigungstyp unterstützt, um die Flexibilität zu erhöhen. Wenn Sie das <permission>-Element verwenden möchten und einen bestimmten String oder ein bestimmtes Symbol benötigen, wenden Sie sich an uns.

Verhalten

Wenn der Nutzer mit dem <permission>-Element interagiert, kann er verschiedene Phasen durchlaufen:

• Wenn sie eine Funktion noch nicht zugelassen haben, können sie sie bei jedem Besuch oder nur für den aktuellen Besuch zulassen.

  

• Wenn sie die Funktion zuvor zugelassen haben, können sie sie weiterhin zulassen oder die Zulassung beenden.

  

• Wenn sie eine Funktion zuvor nicht zugelassen haben, können sie sie weiterhin nicht zulassen oder sie dieses Mal zulassen.

  

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 entsprechend. Wenn die Berechtigung erst erteilt werden muss, wird der Nutzer im Text 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 für den Zugriff auf leistungsstarke Funktionen erkennen können, ist die Gestaltung des <permission>-Elements eingeschränkt. Wenn die Formatierungseinschränkungen für Ihren Anwendungsfall nicht geeignet sind, erzählen Sie uns bitte, wie und warum. Auch wenn wir nicht alle Styling-Anforderungen erfüllen können, hoffen wir, nach dem Origin-Test sichere Möglichkeiten zu finden, um mehr Styling des <permission>-Elements zu ermöglichen. In der folgenden Tabelle werden einige Attribute mit Einschränkungen oder besonderen Regeln aufgeführt. Wenn eine der Regeln verletzt wird, wird das <permission>-Element deaktiviert und kann nicht verwendet werden. Alle Versuche, mit ihr zu interagieren, führen zu Ausnahmen, die mit JavaScript abgefangen werden können. Die Fehlermeldung enthält weitere Details zum erkannten 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 oben genannten Ausnahme für outline-offset)
• 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

Außerdem können alle logisch gleichwertigen Eigenschaften verwendet werden (z. B. ist inline-size gleichwertig mit width). Dabei gelten dieselben Regeln wie für das Äquivalent.

Pseudoklassen

Es gibt zwei spezielle Pseudoklassen, mit denen Sie das <permission>-Element basierend auf dem Status gestalten können:

• :granted: Mit der Pseudoklasse :granted können Sie ein spezielles Styling festlegen, wenn eine Berechtigung erteilt wurde.
• :invalid: Mit der Pseudoklasse :invalid können Sie das Element speziell formatieren, wenn es sich in einem ungültigen Status 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, die erfasst werden können:

• onpromptdismiss: Dieses Ereignis wird ausgelöst, wenn der vom Element ausgelöste Berechtigungs-Prompt vom Nutzer geschlossen wird, z. B. durch Klicken auf die Schaltfläche „Schließen“ oder außerhalb des Prompts.

  erkennen.

• onpromptaction: Dieses Ereignis wird ausgelöst, wenn die vom Element ausgelöste Berechtigungsaufforderung aufgelöst wurde, indem der Nutzer eine Aktion in der Aufforderung selbst ausgeführt hat. 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.

  erkennen.

• onvalidationstatuschange: Dieses Ereignis wird ausgelöst, wenn das Element von "valid" zu "invalid" wechselt. Das Element gilt als "valid", wenn der Browser die Integrität des Signals als vertrauenswürdig einstuft, falls der Nutzer darauf klickt. Andernfalls gilt es als "invalid", 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 nichts, wenn der Browser es nicht kennt. Möglicherweise möchten Sie die Unterstützung weiterhin mit JavaScript erkennen, z. B. um eine Berechtigungsaufforderung zu erstellen, die durch einen Klick auf ein reguläres <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, melden Sie sich für den Ursprungstest an. Unter Erste Schritte mit Origin Trials finden Sie eine Anleitung dazu, wie Sie Ihre Website für die Verwendung von Origin Trials vorbereiten. Der Ursprungstest läuft von Chrome 126 bis Chrome 131 (19. Februar 2025).

Demo

Sehen Sie sich die Demo an und den Quellcode auf GitHub. Hier sehen Sie einen Screenshot der Funktion in einem unterstützten Browser.

Feedback

Wir würden gern erfahren, wie <permission> für Ihren Anwendungsfall funktioniert. Sie können gerne auf eines der Probleme im Repository antworten oder ein neues Problem melden. Öffentliche Signale im repo für das <permission>-Element teilen uns und anderen Browsern mit, dass Sie daran interessiert sind.

FAQ

• Warum ist das besser als ein reguläres <button> in Kombination mit der Permissions API? Ein Klick auf <button> ist eine Nutzeraktion, aber Browser können nicht überprüfen, ob sie mit der Anfrage zum Einholen der Berechtigung zusammenhängt. Wenn der Nutzer auf ein <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 das Blockieren 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 Enhancement verwendet werden. In nicht unterstützten Browsern kann ein klassischer Berechtigungsablauf verwendet werden. Zum Beispiel basierend auf dem Klick auf ein reguläres <button>. Das Berechtigungsteam arbeitet auch an einem Polyfill. Markieren Sie das GitHub-Repository mit einem Stern, um benachrichtigt zu werden, wenn es fertig ist.
• Wurde dies mit anderen Browseranbietern besprochen? Das <permission>-Element wurde 2023 auf dem W3C TPAC in einer Breakout-Session aktiv diskutiert. Notizen zur öffentlichen Sitzung Das Chrome-Team hat auch formelle Standardpositionen von beiden Anbietern angefordert (siehe Abschnitt Zugehörige Links). Das <permission>-Element ist ein fortlaufendes Thema von Diskussionen mit anderen Browsern und wir hoffen, es standardisieren zu können.
• Sollte dies tatsächlich ein leeres Element sein? Es wird immer noch aktiv diskutiert, ob <permission> ein leeres Element sein sollte oder nicht. Wenn Sie Feedback haben, können Sie es im Issue hinterlassen.

Weitere Informationen

• Erläuterung
• WebKit Standards Position
• Mozilla Standards Position

Danksagungen

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