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

Thomas Steiner

Er zijn een aantal essentiële 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 <permission> -element. Dit element bevindt zich in de oorspronkelijke testfase van Chrome 126 en we hopen het uiteindelijk te standaardiseren.

Dwingende 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 nodig heeft via de Geolocation API , zullen browsers de gebruiker hierom vragen, vaak met de mogelijkheid om die beslissing op te slaan. Dit is een goed gedefinieerd concept in de Permissions-specificatie.

Impliciet vragen bij het eerste gebruik versus expliciet vooraf vragen

De Geolocation API is een krachtige API en is gebaseerd op de impliciete vraag bij eerste gebruik-aanpak. 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 vaak een expliciete manier om toestemming aan te vragen via een statische methode zoals Notification.requestPermission() of DeviceMotionEvent.requestPermission() .

Uitdagingen bij dwingende methoden om toestemming te vragen

Toestemmingsspam

Vroeger konden websites methoden zoals navigator.mediaDevices.getUserMedia() of Notification.requestPermission() , maar ook navigator.geolocation.getCurrentPosition() direct aanroepen wanneer een website werd geladen. Er verscheen dan een toestemmingsprompt voordat de gebruiker met de website had geinteracteerd. Dit wordt soms omschreven als toestemmingspam en beïnvloedt beide benaderingen: impliciet vragen bij het eerste gebruik en expliciet vragen vooraf.

Browserbeperkingen en vereisten voor gebruikersgebaren

Toestemmingsspam leidde ertoe dat browserleveranciers een gebruikersgebaar, zoals een klik op een knop of het indrukken van een toets, vereisten voordat een toestemmingsprompt werd getoond. Het probleem met deze aanpak is dat het voor de browser erg moeilijk, zo niet onmogelijk, is om te bepalen of een bepaald gebruikersgebaar moet resulteren in een toestemmingsprompt of niet. Misschien klikte de gebruiker gewoon ergens gefrustreerd op de pagina omdat het laden van de pagina zo lang duurde, of misschien klikte hij of zij wel degelijk op de knop ' Zoek mij' . Sommige websites zijn er ook erg goed in geworden om gebruikers te verleiden om op content te klikken om de prompt te activeren.

Een andere oplossing is het toevoegen van maatregelen tegen misbruik. Zo worden functies vanaf het begin volledig geblokkeerd of wordt de toestemmingsprompt op een niet-modale, minder opdringerige manier weergegeven.

Toestemmingscontextualisatie

Een andere uitdaging, vooral op grote schermen, is de manier waarop de toestemmingsprompt doorgaans wordt weergegeven: boven de grens van de dood , dat wil zeggen buiten het gebied van het browservenster waar de app op kan tekenen. Het is niet ongehoord dat gebruikers de toestemmingsprompt boven in hun browservenster missen wanneer ze gewoon op een knop onderin het venster klikken. Dit probleem wordt vaak verergerd wanneer er spambeperkingen in de browser zijn ingesteld.

Geen gemakkelijke ongedaanmaking

Ten slotte is het voor gebruikers te gemakkelijk om zichzelf in een doodlopende weg te manoeuvreren. Als de gebruiker bijvoorbeeld de toegang tot een functie heeft geblokkeerd, moet hij of zij de dropdown met site-informatie raadplegen om de rechten te resetten of geblokkeerde rechten weer in te schakelen. In het ergste geval moeten beide opties de pagina volledig herladen totdat de bijgewerkte instelling van kracht wordt. Sites bieden geen eenvoudige snelkoppeling waarmee gebruikers een bestaande toestemmingsstatus kunnen wijzigen en moeten gebruikers nauwgezet uitleggen hoe ze hun instellingen kunnen wijzigen, zoals te zien is onderaan de volgende schermafbeelding van Google Maps.

Als de toestemming essentieel is voor de ervaring, bijvoorbeeld toegang tot de microfoon voor een videoconferentietoepassing, tonen apps als Google Meet opdringerige dialoogvensters waarin de gebruiker wordt uitgelegd hoe hij de toestemming kan deblokkeren.

Een declaratief <permission> -element

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

<permission type="camera" />

Er wordt nog steeds actief gediscussieerd over de vraag of <permission> een void-element zou moeten zijn of niet. Een void-element is een zelfsluitend element in HTML dat geen onderliggende nodes kan hebben, wat in HTML betekent dat het geen eindtag mag hebben.

Het type attribuut

Het type attribuut bevat een door spaties gescheiden lijst met de rechten 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 knoppen met een eenvoudige user-agent-stijl.

Het type-ext kenmerk

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

Het lang attribuut

De knoptekst wordt door de browser aangeleverd en is bedoeld om consistent te zijn. Deze kan dus niet rechtstreeks worden aangepast. De browser wijzigt de taal van de tekst op basis van de overgeërfde taal van het document, de bovenliggende elementenketen 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 testfase, kunnen er voor elk type toestemming meerdere strings of pictogrammen worden ondersteund om de flexibiliteit te vergroten. Bent u geïnteresseerd in het gebruik van het <permission> -element en heeft u een specifieke string of pictogram nodig? Neem dan contact met ons op !

Gedrag

Wanneer de gebruiker met het <permission> -element interageert, kan hij/zij verschillende fasen doorlopen:

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

  

• Als ze de functie eerder hebben toegestaan, kunnen ze deze blijven toestaan ​​of stopzetten.

  

• Als ze een functie eerder hebben geblokkeerd, kunnen ze deze blijven blokkeren of deze functie 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 in de melding dat de functie is toegestaan. Als er eerst toestemming moet worden verleend, verandert de tekst in een uitnodiging aan de gebruiker om 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 styling van het <permission> -element beperkt. Als de stylingbeperkingen niet werken voor uw use case, horen we graag hoe en waarom! Hoewel niet aan alle stylingbehoeften kan worden voldaan, hopen we veilige manieren te vinden om meer styling van het <permission> -element mogelijk te maken na de oorspronkelijke proefperiode. De volgende tabel beschrijft enkele eigenschappen waarop beperkingen of speciale regels van toepassing zijn. Als een van de regels wordt overtreden, wordt het <permission> -element uitgeschakeld en is interactie met het element niet mogelijk. Pogingen om ermee te interacteren, resulteren in uitzonderingen die met JavaScript kunnen worden afgevangen. De foutmelding bevat meer details over de gedetecteerde overtreding.

De volgende CSS-eigenschappen kunnen zoals 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 equivalent aan width ), volgens dezelfde regels als hun equivalent.

Pseudo-klassen

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

• :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 geserveerd 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 gebeurtenissen waarnaar kan worden geluisterd:

• 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 wordt geactiveerd, is opgelost door de gebruiker die een actie op de prompt zelf heeft uitgevoerd. Dit betekent niet noodzakelijkerwijs dat de toestemmingsstatus is gewijzigd; de gebruiker kan een actie hebben uitgevoerd die de status quo handhaaft (zoals het toestaan ​​van een toestemming).

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

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

Functiedetectie

Als een browser een HTML-element niet ondersteunt, wordt het niet weergegeven. Dit betekent dat als u het <permission> -element in uw HTML-code hebt, er niets gebeurt als de browser het niet herkent. U kunt ondersteuning toch 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.
}

Oorsprongsproef

Meld u aan voor de proefperiode van Origin om het <permission> -element op uw site met echte gebruikers uit te proberen. Lees 'Aan de slag met Origin-proefperiodes' voor instructies over hoe u uw site kunt voorbereiden op het gebruik van Origin-proefperiodes. De proefperiode van Origin loopt van Chrome 126 tot en met 131 (19 februari 2025).

Demonstratie

Bekijk de demo en 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 use case. U kunt reageren op een van de issues in de repository of een nieuw issue indienen. Openbare signalen in de repository voor het <permission> -element laten ons en andere browsers weten dat u hierin geïnteresseerd bent.

Veelgestelde vragen

• Waarin is dit beter dan een gewone <button> in combinatie met de Permissions API? Een klik op een <button> is een gebruikersgebaar, maar browsers kunnen niet verifiëren of dit verband houdt met het verzoek om toestemming. Als de gebruiker op een <permission> heeft geklikt, kan de browser er zeker van zijn dat de klik verband houdt met een verzoek om toestemming. Dit stelt de browser in staat om processen te faciliteren die anders veel riskanter zouden zijn. Bijvoorbeeld door de gebruiker de mogelijkheid te geven om de blokkering van een machtiging eenvoudig ongedaan te maken.
• Wat als andere browsers het <permission> -element niet ondersteunen? Het <permission> -element kan als een progressieve verbetering worden gebruikt. In browsers die dit niet ondersteunen, kan een klassieke permissiestroom worden gebruikt, bijvoorbeeld gebaseerd op het klikken op een gewone <button> . Het permissieteam werkt ook aan een polyfill. Markeer de GitHub-repository om een ​​melding te ontvangen wanneer deze klaar is.
• Is dit met andere browserleveranciers besproken? Het <permission> -element werd actief besproken tijdens een breakout-sessie van het W3C TPAC in 2023. U kunt de openbare sessienotities lezen. Het Chrome-team heeft ook om formele standaardposities van beide leveranciers gevraagd; zie de sectie Gerelateerde links . Het <permission> -element is een doorlopend onderwerp van discussie met andere browsers en we hopen het te standaardiseren.
• Zou dit eigenlijk een void-element moeten zijn? Er wordt nog steeds actief gediscussieerd over de vraag of <permission> wel of niet een void-element zou moeten zijn. Als je feedback hebt, reageer dan op het probleem.

Gerelateerde links

• Uitlegger
• WebKit-standaardpositie
• Mozilla-standaardpositie

Dankbetuigingen

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