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

Thomas Steiner

Er zijn een aantal dwingende methoden om toestemming te vragen voor het gebruik van krachtige functies, zoals locatietoegang in webapps. Deze methoden brengen een aantal uitdagingen met zich mee. Daarom experimenteert het Chrome-machtigingsteam met een nieuwe declaratieve methode: een speciaal HTML-element <permission> . Dit element is oorspronkelijk een proefversie van Chrome 126 en uiteindelijk hopen we het te standaardiseren.

Imperatieve methoden voor het aanvragen van toestemming

Wanneer webapps toegang nodig hebben tot krachtige functies , moeten ze om toestemming vragen. Wanneer Google Maps bijvoorbeeld de locatie van de gebruiker vereist met behulp van de Geolocation API , zullen browsers de gebruiker hierom vragen, vaak met de optie om die beslissing op te slaan. Dit is een goed gedefinieerd concept in de machtigingenspecificatie.

Impliciet vragen bij het eerste gebruik versus expliciet vooraf vragen

De Geolocatie-API is een krachtige API en vertrouwt op de impliciete vraag bij eerste gebruik. Wanneer een app bijvoorbeeld de methode navigator.geolocation.getCurrentPosition() aanroept, verschijnt de toestemmingsprompt 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 dwingende methoden om toestemming te vragen

Toestemmingspam

In het verleden konden websites methoden als navigator.mediaDevices.getUserMedia() of Notification.requestPermission() , maar ook navigator.geolocation.getCurrentPosition() onmiddellijk aanroepen wanneer een website werd geladen. Er verscheen een toestemmingsprompt voordat de gebruiker interactie had gehad met de website. Dit wordt soms omschreven als toestemmingsspam en heeft invloed op beide benaderingen, waarbij zowel impliciet wordt gevraagd bij het eerste gebruik als expliciet vooraf wordt gevraagd.

Browserbeperkingen en vereisten voor gebruikersgebaren

Toestemmingspam leidde ertoe dat browserleveranciers een gebruikersgebaar vereisten, zoals een klik op een knop of een toetsaanslaggebeurtenis, voordat een toestemmingsprompt werd weergegeven. Het probleem met deze aanpak is dat het voor de browser erg moeilijk, zo niet onmogelijk, is om erachter te komen of een bepaald gebruikersgebaar ertoe moet leiden dat er een toestemmingsprompt wordt weergegeven of niet. Misschien klikte de gebruiker ergens gefrustreerd op de pagina omdat het zo lang duurde om de pagina te laden, of misschien klikten ze inderdaad op de knop 'Zoek mij' . Sommige websites werden ook erg goed in het misleiden van gebruikers om op inhoud te klikken om de prompt te activeren.

Een andere oplossing is het toevoegen van onmiddellijke maatregelen tegen misbruik, zoals het volledig blokkeren van functies om te beginnen, 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 lijn des doods , dat wil zeggen buiten het gebied van het browservenster waar de app gebruik van kan maken. Het is niet ongehoord dat gebruikers de prompt bovenaan hun browservenster missen als ze gewoon op een knop onderaan het venster klikken. Dit probleem wordt vaak verergerd als er maatregelen tegen spam in de browser worden getroffen.

Geen gemakkelijk ongedaan maken

Ten slotte is het voor gebruikers te gemakkelijk om zichzelf in een doodlopende weg te belanden. Zodra de gebruiker bijvoorbeeld de toegang tot een functie heeft geblokkeerd, moet hij op de hoogte zijn van de vervolgkeuzelijst met site-informatie, waarin hij de machtigingen opnieuw kan instellen of de geblokkeerde machtigingen weer kan inschakelen. In het ergste geval vereisen beide opties dat de pagina volledig opnieuw wordt geladen totdat de bijgewerkte instelling van kracht wordt. Sites hebben geen mogelijkheid om gebruikers een gemakkelijke snelkoppeling te bieden om een ​​bestaande toestemmingsstatus te wijzigen en moeten gebruikers nauwgezet uitleggen hoe ze hun instellingen kunnen wijzigen, zoals weergegeven onderaan de volgende Google Maps-screenshot.

Als de toestemming van cruciaal belang is voor de ervaring, bijvoorbeeld microfoontoegang voor een applicatie voor videoconferenties, tonen apps zoals Google Meet opdringerige dialogen die de gebruiker instrueren hoe hij de toestemming kan deblokkeren.

Een declaratief <permission> -element

Om de uitdagingen aan te pakken die in dit bericht worden beschreven, heeft het Chrome-machtigingsteam een ​​origin-proefversie gelanceerd voor een nieuw HTML-element, <permission> . Met dit element kunnen ontwikkelaars declaratief om toestemming vragen om voorlopig een subset van de krachtige functies te gebruiken die beschikbaar zijn voor websites. In de eenvoudigste vorm gebruik je het zoals in het volgende voorbeeld:

<permission type="camera" />

Er wordt nog steeds actief gedebatteerd of <permission> een ongeldig element moet zijn of niet. Een void-element is een zelfsluitend element in HTML dat geen onderliggende knooppunten kan hebben, wat in HTML betekent dat het mogelijk geen eindtag heeft.

Het type

Het type bevat een door spaties gescheiden lijst met machtigingen die u aanvraagt. Op het moment dat dit artikel wordt geschreven, zijn de toegestane waarden 'camera' , 'microphone' en camera microphone (gescheiden door spatie). Dit element wordt standaard weergegeven als knoppen met barebones user-agent-stijl.

Het type-ext attribuut

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

Het lang attribuut

De knoptekst wordt door de browser aangeleverd en is consistent bedoeld, zodat deze niet direct kan worden aangepast. De browser verandert de taal van de tekst op basis van de overgenomen 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 gaat dan de oorspronkelijke proeffase, kunnen er voor elk toestemmingstype verschillende tekenreeksen of pictogrammen worden ondersteund om de flexibiliteit te vergroten. Als u geïnteresseerd bent in het gebruik van het <permission> -element en een specifieke tekenreeks of pictogram nodig heeft, neem dan contact met ons op !

Gedrag

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

• Als ze een functie nog niet eerder hebben toegestaan, kunnen ze deze bij elk bezoek toestaan, of deze voor het huidige bezoek toestaan.

  

• Als ze de functie eerder hadden toegestaan, kunnen ze deze blijven toestaan ​​of niet meer toestaan.

  

• Als ze een functie eerder niet hebben toegestaan, kunnen ze deze functie nog steeds niet toestaan, of deze deze keer wel toestaan.

  

De tekst van het <permission> -element wordt automatisch bijgewerkt op basis van de status. Als er bijvoorbeeld toestemming is verleend om een ​​functie te gebruiken, verandert de tekst om aan te geven dat de functie is toegestaan. Als er eerst toestemming moet worden verleend, verandert de tekst om de gebruiker uit te nodigen de functie te gebruiken. Vergelijk de eerdere schermafbeelding met de volgende schermafbeelding om de twee statussen te zien.

CSS-ontwerp

Om ervoor te zorgen dat gebruikers de knop gemakkelijk kunnen herkennen als een oppervlak voor toegang tot krachtige mogelijkheden, is de stijl van het <permission> -element beperkt. Als de stylingbeperkingen niet werken voor jouw gebruik, horen we graag het hoe en waarom! Hoewel niet aan alle stylingbehoeften kan worden voldaan, hopen we veilige manieren te ontdekken om na de origin-proefperiode meer styling van het <permission> -element mogelijk te maken. In de volgende tabel worden enkele eigenschappen beschreven waarop beperkingen of speciale regels van toepassing zijn. Als een van de regels wordt overtreden, wordt het <permission> -element uitgeschakeld en kan er geen interactie meer mee plaatsvinden. Elke poging om ermee te communiceren zal resulteren in uitzonderingen die kunnen worden opgevangen met JavaScript. Het foutbericht bevat meer details over de gedetecteerde overtreding.

De volgende CSS-eigenschappen kunnen normaal 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 de eerder genoemde uitzondering voor 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 ( inline-size is bijvoorbeeld gelijk aan width ), waarbij dezelfde regels worden gevolgd als hun equivalent.

Pseudo-klassen

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

• :granted : De :granted pseudo-klasse maakt een speciale stijl mogelijk wanneer toestemming is verleend.
• :invalid : De :invalid pseudo-klasse maakt een speciale stijl mogelijk wanneer het element een ongeldige status heeft, bijvoorbeeld wanneer het wordt aangeboden in een cross-origin iframe.

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 om samen met de Permissions API te worden gebruikt. Er zijn een aantal evenementen waar naar geluisterd kan worden:

• onpromptdismiss : deze gebeurtenis wordt geactiveerd wanneer de toestemmingsprompt die door het element wordt geactiveerd, door de gebruiker is afgewezen (bijvoorbeeld door op de knop Sluiten te klikken of door buiten de prompt te klikken).

• onpromptaction : deze gebeurtenis wordt geactiveerd wanneer de toestemmingsprompt die door het element wordt geactiveerd, is opgelost doordat de gebruiker actie heeft ondernomen op de prompt zelf. Dit betekent niet noodzakelijkerwijs dat de toestemmingsstatus is gewijzigd; de gebruiker heeft mogelijk een actie ondernomen die de status quo handhaaft (zoals het blijven verlenen van toestemming).

• onvalidationstatuschange : Deze gebeurtenis wordt geactiveerd wanneer het element overschakelt van "valid" naar "invalid" . Het element wordt als "valid" beschouwd als de browser de integriteit van het signaal vertrouwt als de gebruiker erop zou klikken, en als "invalid" anders, bijvoorbeeld als het element gedeeltelijk wordt afgedekt door andere HTML-inhoud.

U kunt gebeurtenislisteners voor deze gebeurtenissen rechtstreeks inline in de HTML-code registreren ( <permission type="…" onpromptdismiss="alert('The prompt was dismissed');" /> ), of met behulp van addEventListener() op de <permission> element, zoals weergegeven in het volgende voorbeeld.

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

Functiedetectie

Als een browser een HTML-element niet ondersteunt, wordt dit niet weergegeven. Dit betekent dat als u het <permission> -element in uw HTML-code hebt, er niets gebeurt als de browser dit niet weet. Mogelijk wilt u nog steeds ondersteuning detecteren met behulp van JavaScript, bijvoorbeeld om een ​​toestemmingsprompt te maken die wordt geactiveerd door een klik op een gewone <button> .

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

Oorsprong proef

Als u het <permission> -element op uw site wilt uitproberen met echte gebruikers, meldt u zich aan voor de origin-proefperiode . Lees Aan de slag met origin-tests voor instructies over hoe u uw site kunt voorbereiden op het gebruik van origin-tests. De Origin-proefperiode loopt van Chrome 126 tot 131 (19 februari 2025).

Demo

Verken de demo en bekijk de broncode op GitHub. Hier is een screenshot van de ervaring in een ondersteunende browser.

Feedback

We horen graag van u hoe <permission> werkt voor uw gebruiksscenario. Reageer gerust op een van de Issues in de repository , of dien een nieuwe in. Openbare signalen in de repository voor het <permission> -element laten ons en andere browsers weten dat u hierin geïnteresseerd bent.

Veelgestelde vragen

• Hoe is dit beter dan een gewone <button> gekoppeld aan de Permissions API? Een klik op een <button> is een gebruikersgebaar, maar browsers kunnen op geen enkele manier verifiëren of dit verband houdt met het verzoek om toestemming. Als de gebruiker op <permission> heeft geklikt, kan de browser er zeker van zijn dat de klik verband houdt met een toestemmingsverzoek. Hierdoor kan de browser stromen faciliteren die anders veel riskanter zouden zijn. Zo kan de gebruiker bijvoorbeeld eenvoudig de blokkering van een toestemming ongedaan maken.
• Wat moet ik doen als andere browsers het <permission> -element niet ondersteunen? Het <permission> -element kan worden gebruikt als een progressieve verbetering. Op niet-ondersteunende browsers kan een klassieke toestemmingsstroom worden gebruikt. Bijvoorbeeld op basis van de klik op een gewone <button> . Het machtigingsteam werkt ook aan een polyfill. Geef de GitHub-repository een ster om een ​​melding te krijgen wanneer deze gereed is.
• Is dit besproken met andere browserleveranciers? Het <permission> -element werd actief besproken tijdens W3C TPAC in 2023 tijdens een breakout-sessie . U kunt de openbare sessienotities lezen. Het Chrome-team heeft ook om formele standaardposities van beide leveranciers gevraagd, zie het gedeelte Gerelateerde links . Het <permission> -element is een voortdurend onderwerp van discussie met andere browsers en we hopen het te standaardiseren.
• Moet dit eigenlijk een leegte-element zijn? Er wordt nog steeds actief gedebatteerd of <permission> een ongeldig element moet zijn of niet. Als u feedback heeft, kunt u zich melden bij het probleem.

Gerelateerde links

• Uitlegger
• Positie van WebKit-standaarden
• Mozilla-standaardpositie

Dankbetuigingen

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