Een origin-proefversie voor een nieuwe HTML <permission> element

Thomas Steiner

Er bestaan ​​diverse imperatieve methoden om toestemming te vragen voor het gebruik van krachtige functies zoals locatietoegang in webapps. Deze methoden brengen echter een aantal uitdagingen met zich mee. Daarom experimenteert het Chrome-team dat zich bezighoudt met machtigingen met een nieuwe declaratieve methode: een speciaal HTML-element, ` <permission> `. Dit element is in ontwikkeling sinds Chrome 126 en we hopen het uiteindelijk te standaardiseren.

Essentiële methoden voor het aanvragen van toestemming

Wanneer webapplicaties toegang nodig hebben tot krachtige functies , moeten ze daarvoor toestemming vragen. Als Google Maps bijvoorbeeld de locatie van de gebruiker nodig heeft via de Geolocation API , zullen browsers de gebruiker hierom vragen, vaak met de optie om die keuze op te slaan. Dit is een goed gedefinieerd concept in de Permissions-specificatie.

Impliciet vragen bij het eerste gebruik versus expliciet vooraf verzoeken

De Geolocation API is een krachtige API die gebruikmaakt van de impliciete vraag bij het eerste gebruik. Wanneer een app bijvoorbeeld de methode navigator.geolocation.getCurrentPosition() aanroept, verschijnt de prompt voor toestemming automatisch bij de eerste aanroep. Een ander voorbeeld is navigator.mediaDevices.getUserMedia() .

Andere API's, zoals de Notification API of de Device Orientation and Motion API , hebben doorgaans een expliciete manier om toestemming te vragen via een statische methode zoals Notification.requestPermission() of DeviceMotionEvent.requestPermission() .

Uitdagingen met gebiedende methoden voor het vragen om toestemming.

Toestemmingsspam

In het verleden konden websites methoden zoals navigator.mediaDevices.getUserMedia() of Notification.requestPermission() aanroepen, maar ook navigator.geolocation.getCurrentPosition() direct na het laden van een website. Er verscheen dan een toestemmingsprompt voordat de gebruiker interactie had met de website. Dit wordt soms omschreven als 'toestemmingsspam' en treft beide benaderingen: impliciet vragen bij het eerste gebruik, maar ook expliciet vooraf vragen.

Browserbeperkingen en vereisten voor gebruikersgebaren

Door de overvloed aan toestemmingsverzoeken moesten browserfabrikanten een gebruikersactie, zoals een muisklik of een toetsaanslag, vereisen voordat een toestemmingsprompt werd weergegeven. Het probleem met deze aanpak is dat het voor de browser erg moeilijk, zo niet onmogelijk, is om te bepalen of een bepaalde gebruikersactie wel of niet moet leiden tot het tonen van een toestemmingsprompt. Misschien klikte de gebruiker gefrustreerd ergens op de pagina omdat het laden zo lang duurde, of misschien klikte hij of zij wel degelijk op de knop 'Mijn locatie '. Sommige websites werden er ook erg goed in om gebruikers te verleiden op content te klikken om de prompt te activeren.

Een andere maatregel is het toevoegen van directe maatregelen om misbruik te voorkomen, zoals het volledig blokkeren van functies of het tonen van de toestemmingsprompt op een niet-modale, minder opdringerige manier.

Contextualisering van toestemming

Een andere uitdaging, vooral op grote schermen, is de manier waarop de toestemmingsprompt doorgaans wordt weergegeven: boven de 'line of death' , oftewel buiten het gebied van het browservenster waarop de app kan tekenen. Het komt regelmatig voor dat gebruikers de prompt bovenaan hun browservenster missen wanneer ze net op een knop onderaan het venster hebben geklikt. Dit probleem wordt vaak verergerd wanneer er browserbeveiligingsmaatregelen zijn getroffen.

Geen gemakkelijke manier om dit ongedaan te maken

Tot slot is het voor gebruikers te gemakkelijk om in een doodlopende straat terecht te komen. Als een gebruiker bijvoorbeeld de toegang tot een functie heeft geblokkeerd, moet hij of zij de informatie in het dropdownmenu van de website raadplegen om de machtigingen te resetten of de geblokkeerde machtigingen weer in te schakelen. In het ergste geval vereisen beide opties een volledige herlading van de pagina voordat de gewijzigde instelling van kracht wordt. Websites bieden geen eenvoudige manier voor gebruikers om een ​​bestaande machtigingsstatus te wijzigen en moeten gebruikers omslachtig uitleggen hoe ze hun instellingen kunnen aanpassen, zoals te zien is onderaan de volgende schermafbeelding van Google Maps.

Als de toestemming essentieel is voor de gebruikerservaring, bijvoorbeeld microfoontoegang voor een videoconferentie-app, tonen apps zoals Google Meet opdringerige dialoogvensters waarin de gebruiker wordt uitgelegd hoe de toestemming kan worden opgeheven.

Een declaratief <permission> -element

Om de in dit bericht beschreven uitdagingen aan te pakken, heeft het Chrome-team voor machtigingen een origin-proef gelanceerd voor een nieuw HTML-element, <permission> . Met dit element kunnen ontwikkelaars op een declaratieve manier toestemming vragen om (voorlopig) een subset van de krachtige functies te gebruiken die beschikbaar zijn voor websites. In de eenvoudigste vorm gebruikt u het zoals in het volgende voorbeeld:

<permission type="camera" />

Er wordt nog steeds actief gedebatteerd of <permission> een leeg element zou moeten zijn of niet. Een leeg element is een zelfsluitend element in HTML dat geen kindelementen kan hebben, wat in HTML betekent dat het geen eindtag mag hebben.

Het type attribuut

Het attribuut type bevat een door spaties gescheiden lijst met de machtigingen die u aanvraagt. Op het moment van schrijven zijn de toegestane waarden 'camera' , 'microphone' en camera microphone (gescheiden door spaties). Dit element wordt standaard weergegeven als een knop met een minimalistische styling voor de user agent.

Het type-ext attribuut

Voor sommige machtigingen die extra parameters toestaan, accepteert het attribuut type-ext sleutel-waardeparen gescheiden door spaties, zoals bijvoorbeeld precise:true voor de geolocatiemachtiging.

Het lang -attribuut

De tekst op de knop wordt door de browser geleverd en is bedoeld om consistent te zijn, waardoor deze niet direct kan worden aangepast. De browser wijzigt de taal van de tekst op basis van de overgeërfde taal van het document of de bovenliggende elementketen, of een optioneel lang attribuut. Dit betekent dat ontwikkelaars het <permission> -element niet zelf hoeven te lokaliseren. Als het <permission> -element verder wordt ontwikkeld dan de testfase, kunnen er meerdere tekstfragmenten of pictogrammen voor elk type toestemming worden ondersteund om de flexibiliteit te vergroten. Als u geïnteresseerd bent in het gebruik van het <permission> -element en een specifiek tekstfragment of pictogram nodig hebt, neem dan contact met ons op !

Gedrag

Wanneer de gebruiker interactie heeft met het <permission> -element, kan hij of zij verschillende fasen doorlopen:

• Als ze een bepaalde functie voorheen niet hadden toegestaan, kunnen ze deze bij elk bezoek toestaan, of alleen voor het huidige bezoek.

  

• Als ze de functie eerder al hadden toegestaan, kunnen ze die blijven toestaan ​​of ermee stoppen.

  

• Als ze een functie eerder hadden geblokkeerd, kunnen ze die blijven blokkeren, of die nu wel toestaan.

  

De tekst van het <permission> -element wordt automatisch bijgewerkt op basis van de status. Als bijvoorbeeld toestemming is verleend om een ​​functie te gebruiken, verandert de tekst in 'De functie is toegestaan'. Als eerst toestemming moet worden verleend, verandert de tekst in 'De gebruiker wordt uitgenodigd om de functie te gebruiken'. Vergelijk de eerdere schermafbeelding met de volgende schermafbeelding om de twee staten te zien.

CSS-ontwerp

Om ervoor te zorgen dat gebruikers de knop gemakkelijk herkennen als een manier om toegang te krijgen tot krachtige functies, is de styling van het <permission> -element beperkt. Als de stylingbeperkingen niet werken voor uw specifieke gebruikssituatie, horen we graag hoe en waarom! Hoewel niet aan alle stylingbehoeften kan worden voldaan, hopen we na de oorspronkelijke proefperiode veilige manieren te vinden om meer stylingmogelijkheden voor het <permission> -element toe te staan. De volgende tabel geeft een overzicht van enkele eigenschappen waarop beperkingen of speciale regels van toepassing zijn. Als een van de regels wordt overtreden, wordt het <permission> -element uitgeschakeld en kan er niet mee worden gecommuniceerd. Elke poging om ermee te interageren resulteert in uitzonderingen die met JavaScript kunnen worden opgevangen. Het foutbericht bevat meer details over de geconstateerde overtreding.

De volgende CSS-eigenschappen kunnen zoals gebruikelijk worden gebruikt:

• 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 (en alle border-* eigenschappen)
• 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-* (met uitzondering van de eerder genoemde 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

Bovendien kunnen alle logisch equivalente eigenschappen worden gebruikt (bijvoorbeeld, inline-size is equivalent aan width ), volgens dezelfde regels als hun equivalent.

Pseudo-klassen

Er zijn twee speciale pseudo-klassen waarmee het <permission> -element op basis van de status kan worden gestyled:

• :granted : De pseudo-klasse :granted maakt speciale styling mogelijk wanneer een toestemming is verleend.
• :invalid : De pseudo-klasse :invalid maakt speciale styling mogelijk wanneer het element zich in een ongeldige staat bevindt, bijvoorbeeld wanneer het wordt weergegeven in een iframe van een andere oorsprong.

permission {
  background-color: green;
}

permission:granted {
  background-color: light-green;
}

/* Not supported during the origin trial. */
permission:invalid {
  background-color: gray;
}

JavaScript-gebeurtenissen

Het <permission> -element is bedoeld voor gebruik in combinatie met de Permissions API . Er zijn een aantal gebeurtenissen waarop geluisterd kan worden:

• onpromptdismiss : Deze gebeurtenis wordt geactiveerd wanneer de toestemmingsprompt die door het element is geactiveerd, door de gebruiker is gesloten (bijvoorbeeld door op de sluitknop te klikken of buiten de prompt te klikken).

• onpromptaction : Deze gebeurtenis wordt geactiveerd wanneer de toestemmingsprompt die door het element is geactiveerd, is afgehandeld doordat de gebruiker een actie op de prompt zelf heeft uitgevoerd. Dit betekent niet noodzakelijkerwijs dat de toestemmingsstatus is gewijzigd; de gebruiker kan een actie hebben ondernomen die de status quo handhaaft (zoals het blijven toestaan ​​van een toestemming).

• onvalidationstatuschange : Deze gebeurtenis wordt geactiveerd wanneer het element verandert van "valid" naar "invalid" . Het element wordt als "valid" beschouwd wanneer de browser de integriteit van het signaal vertrouwt als de gebruiker erop klikt, en als "invalid" in andere gevallen, bijvoorbeeld wanneer het element gedeeltelijk wordt bedekt door andere HTML-inhoud.

Je kunt gebeurtenislisteners voor deze gebeurtenissen rechtstreeks in de HTML-code registreren ( <permission type="…" onpromptdismiss="alert('The prompt was dismissed');" /> ), of door addEventListener() te gebruiken op het <permission> -element, zoals in het volgende voorbeeld wordt getoond.

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

Kenmerkdetectie

Als een browser een HTML-element niet ondersteunt, wordt het niet weergegeven. Dit betekent dat als je het <permission> -element in je HTML-code hebt staan, er niets gebeurt als de browser het niet herkent. Je wilt de ondersteuning mogelijk wel detecteren met behulp van JavaScript, bijvoorbeeld om een ​​toestemmingsprompt te maken die wordt geactiveerd door op een gewone <button> te klikken.

if ('HTMLPermissionElement' in window) {
  // The `<permission>` element is supported.
}

Oorsprongsproef

Om het <permission> -element op uw site met echte gebruikers te testen, meldt u zich aan voor de Origin-proefversie . Lees ' Aan de slag met Origin-proefversies' voor instructies over hoe u uw site kunt voorbereiden op het gebruik van Origin-proefversies. De Origin-proefversie loopt van Chrome versie 126 tot en met 131 (19 februari 2025).

Demo

Verken de demo en bekijk de broncode op GitHub. Hier is een screenshot van hoe het eruitziet in een ondersteunde browser.

Feedback

We horen graag van u hoe <permission> in uw specifieke situatie werkt. U kunt reageren op een van de issues in de repository of een nieuwe issue aanmaken. Openbare signalen in de repository voor het <permission> -element laten ons en andere browsers weten dat u erin geïnteresseerd bent.

Veelgestelde vragen

• Hoe is dit beter dan een gewone <button> in combinatie met de Permissions API? Een klik op een <button> is een gebruikersactie, maar browsers kunnen niet controleren of deze klik gekoppeld is aan een toestemmingsverzoek. Als de gebruiker op een <permission> heeft geklikt, kan de browser er zeker van zijn dat de klik verband houdt met een toestemmingsverzoek. Dit maakt het voor de browser mogelijk om processen te faciliteren die anders veel riskanter zouden zijn. Bijvoorbeeld door de gebruiker de mogelijkheid te bieden om de blokkering van een toestemming eenvoudig ongedaan te maken.
• Wat als andere browsers het <permission> -element niet ondersteunen? Het <permission> -element kan worden gebruikt als een progressieve verbetering. In browsers die het niet ondersteunen, kan een klassieke toestemmingsprocedure worden gebruikt. Bijvoorbeeld op basis van een klik op een gewone <button> . Het toestemmingsteam werkt ook aan een polyfill. Geef de GitHub-repository een ster om een ​​melding te ontvangen wanneer deze klaar is.
• Is dit besproken met andere browserleveranciers? Het <permission> -element werd actief besproken tijdens de W3C TPAC in 2023 in een aparte sessie . U kunt de notulen van de openbare sessie lezen. Het Chrome-team heeft beide leveranciers ook gevraagd om formele standpunten over de standaarden in te dienen; zie de sectie 'Gerelateerde links' . Het <permission> -element is een onderwerp van voortdurende discussie met andere browsers en we hopen het te standaardiseren.
• Zou dit eigenlijk een leeg element moeten zijn? Er wordt nog steeds actief gedebatteerd of <permission> een leeg element zou moeten zijn of niet. Als je feedback hebt, laat het dan weten in de discussie.

Gerelateerde links

• Uitleg
• Standpunt over WebKit-standaarden
• Standpunt van Mozilla over standaarden

Dankbetuigingen

Dit document is beoordeeld door Balázs Engedy , Thomas Nguyen , Penelope McLachlan , Marian Harbach , David Warren en Rachel Andrew .

Thomas Steiner

Er bestaan ​​diverse imperatieve methoden om toestemming te vragen voor het gebruik van krachtige functies zoals locatietoegang in webapps. Deze methoden brengen echter een aantal uitdagingen met zich mee. Daarom experimenteert het Chrome-team dat zich bezighoudt met machtigingen met een nieuwe declaratieve methode: een speciaal HTML-element, ` <permission> `. Dit element is in ontwikkeling sinds Chrome 126 en we hopen het uiteindelijk te standaardiseren.

Essentiële methoden voor het aanvragen van toestemming

Wanneer webapplicaties toegang nodig hebben tot krachtige functies , moeten ze daarvoor toestemming vragen. Als Google Maps bijvoorbeeld de locatie van de gebruiker nodig heeft via de Geolocation API , zullen browsers de gebruiker hierom vragen, vaak met de optie om die keuze op te slaan. Dit is een goed gedefinieerd concept in de Permissions-specificatie.

Impliciet vragen bij het eerste gebruik versus expliciet vooraf verzoeken

De Geolocation API is een krachtige API die gebruikmaakt van de impliciete vraag bij het eerste gebruik. Wanneer een app bijvoorbeeld de methode navigator.geolocation.getCurrentPosition() aanroept, verschijnt de prompt voor toestemming automatisch bij de eerste aanroep. Een ander voorbeeld is navigator.mediaDevices.getUserMedia() .

Andere API's, zoals de Notification API of de Device Orientation and Motion API , hebben doorgaans een expliciete manier om toestemming te vragen via een statische methode zoals Notification.requestPermission() of DeviceMotionEvent.requestPermission() .

Uitdagingen met gebiedende methoden voor het vragen om toestemming.

Toestemmingsspam

In het verleden konden websites methoden zoals navigator.mediaDevices.getUserMedia() of Notification.requestPermission() aanroepen, maar ook navigator.geolocation.getCurrentPosition() direct na het laden van een website. Er verscheen dan een toestemmingsprompt voordat de gebruiker interactie had met de website. Dit wordt soms omschreven als 'toestemmingsspam' en treft beide benaderingen: impliciet vragen bij het eerste gebruik, maar ook expliciet vooraf vragen.

Browserbeperkingen en vereisten voor gebruikersgebaren

Door de overvloed aan toestemmingsverzoeken moesten browserfabrikanten een gebruikersactie, zoals een muisklik of een toetsaanslag, vereisen voordat een toestemmingsprompt werd weergegeven. Het probleem met deze aanpak is dat het voor de browser erg moeilijk, zo niet onmogelijk, is om te bepalen of een bepaalde gebruikersactie wel of niet moet leiden tot het tonen van een toestemmingsprompt. Misschien klikte de gebruiker gefrustreerd ergens op de pagina omdat het laden zo lang duurde, of misschien klikte hij of zij wel degelijk op de knop 'Mijn locatie '. Sommige websites werden er ook erg goed in om gebruikers te verleiden op content te klikken om de prompt te activeren.

Een andere maatregel is het toevoegen van directe maatregelen om misbruik te voorkomen, zoals het volledig blokkeren van functies of het tonen van de toestemmingsprompt op een niet-modale, minder opdringerige manier.

Contextualisering van toestemming

Een andere uitdaging, vooral op grote schermen, is de manier waarop de toestemmingsprompt doorgaans wordt weergegeven: boven de 'line of death' , oftewel buiten het gebied van het browservenster waarop de app kan tekenen. Het komt regelmatig voor dat gebruikers de prompt bovenaan hun browservenster missen wanneer ze net op een knop onderaan het venster hebben geklikt. Dit probleem wordt vaak verergerd wanneer er browserbeveiligingsmaatregelen zijn getroffen.

Geen gemakkelijke manier om dit ongedaan te maken

Tot slot is het voor gebruikers te gemakkelijk om in een doodlopende straat terecht te komen. Als een gebruiker bijvoorbeeld de toegang tot een functie heeft geblokkeerd, moet hij of zij de informatie in het dropdownmenu van de website raadplegen om de machtigingen te resetten of de geblokkeerde machtigingen weer in te schakelen. In het ergste geval vereisen beide opties een volledige herlading van de pagina voordat de gewijzigde instelling van kracht wordt. Websites bieden geen eenvoudige manier voor gebruikers om een ​​bestaande machtigingsstatus te wijzigen en moeten gebruikers omslachtig uitleggen hoe ze hun instellingen kunnen aanpassen, zoals te zien is onderaan de volgende schermafbeelding van Google Maps.

Als de toestemming essentieel is voor de gebruikerservaring, bijvoorbeeld microfoontoegang voor een videoconferentie-app, tonen apps zoals Google Meet opdringerige dialoogvensters waarin de gebruiker wordt uitgelegd hoe de toestemming kan worden opgeheven.

Een declaratief <permission> -element

Om de in dit bericht beschreven uitdagingen aan te pakken, heeft het Chrome-team voor machtigingen een origin-proef gelanceerd voor een nieuw HTML-element, <permission> . Met dit element kunnen ontwikkelaars op een declaratieve manier toestemming vragen om (voorlopig) een subset van de krachtige functies te gebruiken die beschikbaar zijn voor websites. In de eenvoudigste vorm gebruikt u het zoals in het volgende voorbeeld:

<permission type="camera" />

Er wordt nog steeds actief gedebatteerd of <permission> een leeg element zou moeten zijn of niet. Een leeg element is een zelfsluitend element in HTML dat geen kindelementen kan hebben, wat in HTML betekent dat het geen eindtag mag hebben.

Het type attribuut

Het attribuut type bevat een door spaties gescheiden lijst met de machtigingen die u aanvraagt. Op het moment van schrijven zijn de toegestane waarden 'camera' , 'microphone' en camera microphone (gescheiden door spaties). Dit element wordt standaard weergegeven als een knop met een minimalistische styling voor de user agent.

Het type-ext attribuut

Voor sommige machtigingen die extra parameters toestaan, accepteert het attribuut type-ext sleutel-waardeparen gescheiden door spaties, zoals bijvoorbeeld precise:true voor de geolocatiemachtiging.

Het lang -attribuut

De tekst op de knop wordt door de browser geleverd en is bedoeld om consistent te zijn, waardoor deze niet direct kan worden aangepast. De browser wijzigt de taal van de tekst op basis van de overgeërfde taal van het document of de bovenliggende elementketen, of een optioneel lang attribuut. Dit betekent dat ontwikkelaars het <permission> -element niet zelf hoeven te lokaliseren. Als het <permission> -element verder wordt ontwikkeld dan de testfase, kunnen er meerdere tekstfragmenten of pictogrammen voor elk type toestemming worden ondersteund om de flexibiliteit te vergroten. Als u geïnteresseerd bent in het gebruik van het <permission> -element en een specifiek tekstfragment of pictogram nodig hebt, neem dan contact met ons op !

Gedrag

Wanneer de gebruiker interactie heeft met het <permission> -element, kan hij of zij verschillende fasen doorlopen:

• Als ze een bepaalde functie voorheen niet hadden toegestaan, kunnen ze deze bij elk bezoek toestaan, of alleen voor het huidige bezoek.

  

• Als ze de functie eerder al hadden toegestaan, kunnen ze die blijven toestaan ​​of ermee stoppen.

  

• Als ze een functie eerder hadden geblokkeerd, kunnen ze die blijven blokkeren, of die nu wel toestaan.

  

De tekst van het <permission> -element wordt automatisch bijgewerkt op basis van de status. Als bijvoorbeeld toestemming is verleend om een ​​functie te gebruiken, verandert de tekst in 'De functie is toegestaan'. Als eerst toestemming moet worden verleend, verandert de tekst in 'De gebruiker wordt uitgenodigd om de functie te gebruiken'. Vergelijk de eerdere schermafbeelding met de volgende schermafbeelding om de twee staten te zien.

CSS-ontwerp

Om ervoor te zorgen dat gebruikers de knop gemakkelijk herkennen als een manier om toegang te krijgen tot krachtige functies, is de styling van het <permission> -element beperkt. Als de stylingbeperkingen niet werken voor uw specifieke gebruikssituatie, horen we graag hoe en waarom! Hoewel niet aan alle stylingbehoeften kan worden voldaan, hopen we na de oorspronkelijke proefperiode veilige manieren te vinden om meer stylingmogelijkheden voor het <permission> -element toe te staan. De volgende tabel geeft een overzicht van enkele eigenschappen waarop beperkingen of speciale regels van toepassing zijn. Als een van de regels wordt overtreden, wordt het <permission> -element uitgeschakeld en kan er niet mee worden gecommuniceerd. Elke poging om ermee te interageren resulteert in uitzonderingen die met JavaScript kunnen worden opgevangen. Het foutbericht bevat meer details over de geconstateerde overtreding.

De volgende CSS-eigenschappen kunnen zoals gebruikelijk worden gebruikt:

• 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 (en alle border-* eigenschappen)
• 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-* (met uitzondering van de eerder genoemde 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

Bovendien kunnen alle logisch equivalente eigenschappen worden gebruikt (bijvoorbeeld, inline-size is equivalent aan width ), volgens dezelfde regels als hun equivalent.

Pseudo-klassen

Er zijn twee speciale pseudo-klassen waarmee het <permission> -element op basis van de status kan worden gestyled:

• :granted : De pseudo-klasse :granted maakt speciale styling mogelijk wanneer een toestemming is verleend.
• :invalid : De pseudo-klasse :invalid maakt speciale styling mogelijk wanneer het element zich in een ongeldige staat bevindt, bijvoorbeeld wanneer het wordt weergegeven in een iframe van een andere oorsprong.

permission {
  background-color: green;
}

permission:granted {
  background-color: light-green;
}

/* Not supported during the origin trial. */
permission:invalid {
  background-color: gray;
}

JavaScript-gebeurtenissen

Het <permission> -element is bedoeld voor gebruik in combinatie met de Permissions API . Er zijn een aantal gebeurtenissen waarop geluisterd kan worden:

• onpromptdismiss : Deze gebeurtenis wordt geactiveerd wanneer de toestemmingsprompt die door het element is geactiveerd, door de gebruiker is gesloten (bijvoorbeeld door op de sluitknop te klikken of buiten de prompt te klikken).

• onpromptaction : Deze gebeurtenis wordt geactiveerd wanneer de toestemmingsprompt die door het element is geactiveerd, is afgehandeld doordat de gebruiker een actie op de prompt zelf heeft uitgevoerd. Dit betekent niet noodzakelijkerwijs dat de toestemmingsstatus is gewijzigd; de gebruiker kan een actie hebben ondernomen die de status quo handhaaft (zoals het blijven toestaan ​​van een toestemming).

• onvalidationstatuschange : Deze gebeurtenis wordt geactiveerd wanneer het element verandert van "valid" naar "invalid" . Het element wordt als "valid" beschouwd wanneer de browser de integriteit van het signaal vertrouwt als de gebruiker erop klikt, en als "invalid" in andere gevallen, bijvoorbeeld wanneer het element gedeeltelijk wordt bedekt door andere HTML-inhoud.

Je kunt gebeurtenislisteners voor deze gebeurtenissen rechtstreeks in de HTML-code registreren ( <permission type="…" onpromptdismiss="alert('The prompt was dismissed');" /> ), of door addEventListener() te gebruiken op het <permission> -element, zoals in het volgende voorbeeld wordt getoond.

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

Kenmerkdetectie

Als een browser een HTML-element niet ondersteunt, wordt het niet weergegeven. Dit betekent dat als je het <permission> -element in je HTML-code hebt staan, er niets gebeurt als de browser het niet herkent. Je wilt de ondersteuning mogelijk wel detecteren met behulp van JavaScript, bijvoorbeeld om een ​​toestemmingsprompt te maken die wordt geactiveerd door op een gewone <button> te klikken.

if ('HTMLPermissionElement' in window) {
  // The `<permission>` element is supported.
}

Oorsprongsproef

Om het <permission> -element op uw site met echte gebruikers te testen, meldt u zich aan voor de Origin-proefversie . Lees ' Aan de slag met Origin-proefversies' voor instructies over hoe u uw site kunt voorbereiden op het gebruik van Origin-proefversies. De Origin-proefversie loopt van Chrome versie 126 tot en met 131 (19 februari 2025).

Demo

Verken de demo en bekijk de broncode op GitHub. Hier is een screenshot van hoe het eruitziet in een ondersteunde browser.

Feedback

We would love to hear from you how <permission> works for your use case. Feel free to respond to one of the Issues in the repository , or file a new one. Public signals in the repo for the <permission> element will let us and other browsers know you're interested in it.

Veelgestelde vragen

• How is this better than a regular <button> paired with the Permissions API? A click of a <button> is a user gesture, but browsers have no way of verifying that it's connected to the request for asking for permission. If the user has clicked a <permission> , the browser can be sure that the click is related to a permission request. This allows the browser to facilitate flows that otherwise would be a lot more risky. For example, allowing the user to easily undo the blocking of a permission.
• What if other browsers don't support the <permission> element? The <permission> element can be used as a progressive enhancement. On non-supporting browsers, a classic permission flow can be used. For example, based on the click of a regular <button> . The permissions team are also working on a polyfill. Star the GitHub repo to be notified when it's ready.
• Was this discussed with other browser vendors? The <permission> element was actively discussed at W3C TPAC in 2023 in a breakout session . You can read the public session notes . The Chrome team has also asked for formal Standards Positions from both vendors, see the Related links section. The <permission> element is an ongoing topic of discussions with other browsers and we're hoping to standardize it.
• Should this actually be a void element? It's still being actively debated whether <permission> should be a void element or not. If you have feedback, chime in on the Issue.

Related links

• Uitleg
• WebKit Standards Position
• Mozilla Standards Position

Acknowledgements

This document was reviewed by Balázs Engedy , Thomas Nguyen , Penelope McLachlan , Marian Harbach , David Warren , and Rachel Andrew .