Il existe un certain nombre de méthodes impératives pour demander l'autorisation d'utiliser des fonctionnalités puissantes telles que l'accès à la position dans les applications Web. Ces méthodes présentent un certain nombre de défis. C'est pourquoi l'équipe Chrome chargée des autorisations teste une nouvelle méthode déclarative: un élément HTML <permission> dédié. Cet élément est en phase d'évaluation à partir de Chrome 126 et nous espérons le standardiser à terme.
Méthodes impératives pour demander des autorisations
Lorsque les applications Web ont besoin d'accéder à des fonctionnalités puissantes, elles doivent demander l'autorisation. Par exemple, lorsque Google Maps requiert la position de l'utilisateur à l'aide de l'API Geolocation, les navigateurs affichent une invite l'utilisateur, souvent avec la possibilité de stocker cette décision. Il s'agit d'un concept bien défini dans la spécification des autorisations.
Demander implicitement la première utilisation plutôt que demander explicitement à l'avance
L'API Geolocation est une API performante qui repose sur l'approche implicite de la demande de première utilisation. Par exemple, lorsqu'une application appelle la méthode navigator.geolocation.getCurrentPosition(), l'invite d'autorisation s'affiche automatiquement lors du premier appel.
Un autre exemple est navigator.mediaDevices.getUserMedia().
D'autres API, comme l'API Notification ou l'API Device Orientation and Motion, disposent généralement d'un moyen explicite de demander une autorisation via une méthode statique comme Notification.requestPermission() ou DeviceMotionEvent.requestPermission().
Difficultés liées aux méthodes impératives de demande d'autorisation
Spam lié aux autorisations
Auparavant, les sites Web pouvaient appeler des méthodes telles que navigator.mediaDevices.getUserMedia() ou Notification.requestPermission(), mais aussi navigator.geolocation.getCurrentPosition() immédiatement lorsqu'un site Web était chargé. Une invite d'autorisation apparaissait avant que l'utilisateur n'ait interagi avec le site Web. Cela est parfois décrit comme du spam d'autorisation et affecte les deux approches : demander implicitement lors de la première utilisation ainsi que demander explicitement en amont.
Mesures d'atténuation des risques du navigateur et exigences des utilisateurs concernant les gestes
Le spam lié aux autorisations a conduit les fournisseurs de navigateurs à exiger un geste de l'utilisateur (comme un clic sur un bouton ou un événement de clavier) avant d'afficher une invite d'autorisation. Le problème de cette approche est qu'il est très difficile, voire impossible, pour le navigateur de déterminer si un geste donné de l'utilisateur doit entraîner ou non l'affichage d'une invite d'autorisation. Peut-être que l'utilisateur cliquait simplement sur la page en raison de la frustration du fait que la page mettait beaucoup de temps à se charger, ou qu'il cliquait en effet sur le bouton Me localiser. Certains sites Web sont également devenus très efficaces pour inciter les utilisateurs à cliquer sur le contenu afin de déclencher l'invite.
Une autre mesure d'atténuation consiste à ajouter des mesures d'atténuation des utilisations abusives des invites, telles que le blocage complet de fonctionnalités au départ, ou l'affichage de la demande d'autorisation de manière non modale et moins intrusive.
Contexte des autorisations
Un autre défi, en particulier sur les grands écrans, est la façon dont l'invite d'autorisation s'affiche couramment: au-dessus de la ligne de mort, c'est-à-dire en dehors de la zone de la fenêtre du navigateur sur laquelle l'application peut s'afficher. Il n'est pas rare que les utilisateurs passent à côté de l'invite en haut de la fenêtre du navigateur lorsqu'ils viennent de cliquer sur un bouton en bas de celle-ci. Ce problème est souvent exacerbé lorsque des mesures d'atténuation du spam dans les navigateurs sont en place.
Annulation facile
Enfin, il est trop facile pour les utilisateurs de naviguer dans une impasse. Par exemple, une fois que l'utilisateur a bloqué l'accès à une fonctionnalité, il doit connaître la liste déroulante des informations sur le site, dans lequel il peut Réinitialiser les autorisations ou réactiver les autorisations bloquées. Dans le pire des cas, les deux options nécessitent une actualisation complète de la page jusqu'à ce que le paramètre modifié prenne effet. Les sites ne peuvent pas fournir de raccourci simple permettant aux utilisateurs de modifier un état d'autorisation existant et doivent leur expliquer minutieusement comment modifier leurs paramètres, comme indiqué en bas de la capture d'écran Google Maps suivante.
Si l'autorisation est essentielle à l'expérience, par exemple l'accès au micro pour une application de visioconférence, les applications telles que Google Meet affichent des boîtes de dialogue intrusives qui indiquent à l'utilisateur comment débloquer l'autorisation.
Un élément <permission> déclaratif
Pour résoudre les problèmes décrits dans cet article, l'équipe Chrome chargée des autorisations a lancé une phase d'évaluation pour un nouvel élément HTML, <permission>. Cet élément permet aux développeurs de demander de manière déclarative l'autorisation d'utiliser un sous-ensemble des puissantes fonctionnalités disponibles pour les sites Web. Dans sa forme la plus simple, utilisez-la comme dans l'exemple suivant:
<permission type="camera" />
La question de savoir si <permission> doit être ou non un élément vide est toujours activement débattue. Un élément vide est un élément HTML qui se ferme spontanément et qui ne peut pas avoir de nœuds enfants. En HTML, il ne peut donc pas comporter de balise de fin.
Attribut type
L'attribut type contient une liste d'autorisations que vous demandez, séparées par un espace. Au moment de la rédaction de ce document, les valeurs autorisées sont 'camera', 'microphone' et camera microphone (séparées par un espace). Par défaut, cet élément s'affiche de la même manière que les boutons avec un style user-agent épuré.
Attribut type-ext
Pour certaines autorisations autorisant des paramètres supplémentaires, l'attribut type-ext accepte des paires clé/valeur séparées par un espace, comme precise:true pour l'autorisation de géolocalisation.
Attribut lang
Le texte du bouton est fourni par le navigateur et destiné à être cohérent. Il ne peut donc pas être personnalisé directement. Le navigateur modifie la langue du texte en fonction de la langue héritée du document ou de la chaîne d'éléments parent, ou d'un attribut lang facultatif. Cela signifie que les développeurs n'ont pas besoin de localiser l'élément <permission> eux-mêmes. Si l'élément <permission> dépasse l'étape d'évaluation, plusieurs chaînes ou icônes peuvent être acceptées pour chaque type d'autorisation afin d'accroître la flexibilité. Si vous souhaitez utiliser l'élément <permission> et que vous avez besoin d'une chaîne ou d'une icône spécifique, contactez-nous.
Comportement
Lorsque l'utilisateur interagit avec l'élément <permission>, il peut passer par différentes étapes:
S'il n'avait pas autorisé une fonctionnalité auparavant, il peut l'autoriser à chaque visite ou pour la visite en cours.
S'il avait autorisé cette fonctionnalité auparavant, il peut continuer à l'autoriser ou cesser de l'autoriser.
S'il avait précédemment désactivé une fonctionnalité, il peut continuer ou l'autoriser cette fois-ci.
Le texte de l'élément <permission> est automatiquement mis à jour en fonction de l'état. Par exemple, si l'autorisation d'utiliser une fonctionnalité a été accordée, le texte change pour indiquer que l'élément est autorisé. Si l'autorisation doit d'abord être accordée, le texte change pour inviter l'utilisateur à utiliser la fonctionnalité. Comparez la capture d'écran précédente avec celle suivante pour voir les deux états.
Conception CSS
Pour que les utilisateurs puissent facilement reconnaître le bouton comme une surface permettant d'accéder à de puissantes fonctionnalités, le style de l'élément <permission> est limité. Si les restrictions de style ne sont pas adaptées à votre cas d'utilisation, n'hésitez pas à nous contacter pour en savoir plus. Bien que tous les besoins de style ne puissent pas être satisfaits, nous espérons trouver des moyens sûrs d'appliquer davantage de styles à l'élément <permission> après la phase d'évaluation. Le tableau suivant détaille certaines propriétés auxquelles des restrictions ou des règles spéciales sont appliquées. En cas de non-respect de l'une des règles, l'élément <permission> sera désactivé et vous ne pourrez pas interagir avec celui-ci. Toute tentative d'interaction avec ce fichier entraînera des exceptions qui pourront être interceptées par JavaScript. Le message d'erreur contiendra plus de détails sur le non-respect détecté.
| Propriété | Règles |
|---|---|
|
Permet de définir la couleur du texte et de l'arrière-plan, respectivement. Le contraste entre les deux couleurs doit être suffisant pour que le texte soit clairement lisible (rapport de contraste d'au moins 3). Le canal alpha doit être 1. |
|
Doit être défini de manière équivalente à small et xxxlarge. Sinon, l'élément est désactivé. Le zoom sera pris en compte lors du calcul de font-size. |
|
Les valeurs négatives seront corrigées en 0. |
margin (tout) |
Les valeurs négatives seront corrigées en 0. |
|
Les valeurs sous 200 seront remplacées par 200. |
|
Les valeurs autres que normal et italic seront remplacées par normal. |
|
Les valeurs supérieures à 0.5em seront corrigées en 0.5em. Les valeurs sous 0 seront corrigées en 0. |
|
Les valeurs autres que inline-block et none seront corrigées en inline-block. |
|
Les valeurs supérieures à 0.2em seront corrigées en 0.2em. Les valeurs sous -0.05em seront remplacées par -0.05em. |
|
La valeur par défaut est 1em. Si elle est fournie, la valeur maximale calculée entre les valeurs par défaut et les valeurs fournies sera prise en compte. |
|
La valeur par défaut est 3em. Si elle est fournie, la valeur minimale calculée entre les valeurs par défaut et les valeurs fournies sera prise en compte. |
|
La valeur par défaut est fit-content. Si elle est fournie, la valeur calculée maximale entre les valeurs par défaut et les valeurs fournies sera prise en compte. |
|
Sa valeur par défaut sera 3 fois fit-content. Si elle est fournie, la valeur minimale calculée entre les valeurs par défaut et les valeurs fournies sera prise en compte. |
|
Ne prendra effet que si height est défini sur auto. Dans ce cas, les valeurs supérieures à 1em seront remplacées par 1em et padding-bottom sur la valeur de padding-top. |
|
Ne prendra effet que si width est défini sur auto. Dans ce cas, les valeurs supérieures à 5em seront remplacées par 5em et padding-right sur la valeur de padding-left.. |
|
Les effets visuels déformés ne seront pas autorisés. Pour le moment, nous n'acceptons que la traduction en 2D et l'augmentation proportionnelle à la hausse. |
Les propriétés CSS suivantes peuvent être utilisées normalement:
font-kerningfont-optical-sizingfont-stretchfont-synthesis-weightfont-synthesis-stylefont-synthesis-small-capsfont-feature-settingsforced-color-adjusttext-renderingalign-selfanchor-name aspect-ratioborder(et toutes les propriétésborder-*)clearcolor-schemecontaincontain-intrinsic-widthcontain-intrinsic-heightcontainer-namecontainer-typecounter-*flex-*floatheightisolationjustify-selfleftorderorphansoutline-*(à l'exception notée précédemment pouroutline-offset)overflow-anchoroverscroll-behavior-*pagepositionposition-anchorcontent-visibilityrightscroll-margin-*scroll-padding-*text-spacing-trimtopvisibilityxyruby-positionuser-selectwidthwill-changez-index
En outre, toutes les propriétés logiquement équivalentes peuvent être utilisées (par exemple, inline-size équivaut à width), en suivant les mêmes règles que leurs équivalents.
Pseudo-cours
Il existe deux pseudo-classes spéciales qui permettent de styliser l'élément <permission> en fonction de l'état:
:granted: la pseudo-classe:grantedpermet un style spécial lorsqu'une autorisation a été accordée.:invalid: la pseudo-classe:invalidpermet d'appliquer un style spécial à l'élément lorsque son état n'est pas valide, par exemple lorsqu'il est diffusé dans un iFrame multi-origine.
permission {
background-color: green;
}
permission:granted {
background-color: light-green;
}
/* Not supported during the origin trial. */
permission:invalid {
background-color: gray;
}
Événements JavaScript
L'élément <permission> est destiné à être utilisé avec l'API Permissions.
Un certain nombre d'événements peuvent être écoutés:
onpromptdismiss: cet événement est déclenché lorsque l'invite d'autorisation déclenchée par l'élément a été ignorée par l'utilisateur (par exemple, en cliquant sur le bouton de fermeture ou en cliquant en dehors de l'invite).onpromptaction: cet événement est déclenché lorsque l'invite d'autorisation déclenchée par l'élément a été résolue par l'utilisateur qui effectue lui-même une action sur l'invite. Cela ne signifie pas nécessairement que l'état de l'autorisation a changé. L'utilisateur peut avoir effectué une action qui maintient le statu quo (par exemple, continuer à accorder une autorisation).onvalidationstatuschange: cet événement est déclenché lorsque l'élément passe de"valid"à"invalid". L'élément est considéré comme"valid"lorsque le navigateur fait confiance à l'intégrité du signal si l'utilisateur clique dessus, et"invalid"dans le cas contraire, par exemple lorsqu'il est partiellement masqué par un autre contenu HTML.
Vous pouvez enregistrer des écouteurs d'événements pour ces événements directement intégrés dans le code HTML (<permission type="…" onpromptdismiss="alert('The prompt was dismissed');" />) ou en utilisant addEventListener() sur l'élément <permission>, comme illustré dans l'exemple suivant.
<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>
Détection de caractéristiques
Si un navigateur n'accepte pas un élément HTML, il ne l'affichera pas. Cela signifie que si l'élément <permission> figure dans votre code HTML, rien ne se passe si le navigateur ne le connaît pas. Vous souhaitez peut-être toujours détecter la prise en charge à l'aide de JavaScript, par exemple pour créer une invite d'autorisation déclenchée par un clic sur un <button> standard.
if ('HTMLPermissionElement' in window) {
// The `<permission>` element is supported.
}
Phase d'évaluation
Pour tester l'élément <permission> sur votre site avec des utilisateurs réels, inscrivez-vous à la phase d'évaluation.
Consultez Premiers pas avec les phases d'évaluation pour savoir comment préparer votre site à les utiliser. La phase d'évaluation s'exécutera de Chrome 126 à la version 131 (du 19 février 2025).
Démonstration
Explorez la démonstration et consultez le code source sur GitHub. Voici une capture d'écran de l'expérience sur un navigateur compatible.
Commentaires
Nous aimerions savoir comment <permission> fonctionne pour votre cas d'utilisation. N'hésitez pas à répondre à l'un des problèmes du dépôt ou à en signaler un nouveau. Les signaux publics dans le dépôt de l'élément <permission> nous permettront, ainsi qu'aux autres navigateurs, de savoir qu'il vous intéresse.
Questions fréquentes
- En quoi cette méthode est-elle plus efficace qu'un
<button>standard associé à l'API Permissions ? Un clic sur une<button>est un geste de l'utilisateur, mais les navigateurs ne peuvent pas vérifier qu'il est connecté à la requête de demande d'autorisation. Si l'utilisateur a cliqué sur un<permission>, le navigateur peut être sûr que le clic est lié à une demande d'autorisation. Cela permet au navigateur de faciliter des flux qui, autrement, seraient beaucoup plus risqués. Par exemple, elle permet à l'utilisateur d'annuler facilement le blocage d'une autorisation. - Que se passe-t-il si d'autres navigateurs ne sont pas compatibles avec l'élément
<permission>? L'élément<permission>peut être utilisé comme amélioration progressive. Sur les navigateurs non compatibles, vous pouvez utiliser un flux d'autorisations classique. (par exemple, en fonction du clic sur un<button>standard). L'équipe chargée des autorisations travaille également sur un polyfill. Ajoutez le dépôt GitHub à vos favoris pour être averti lorsqu'il sera prêt. - Avez-vous discuté de ce point avec d'autres fournisseurs de navigateurs ? L'élément
<permission>a fait l'objet d'une discussion active lors d'une session en petit groupe lors du W3C TPAC en 2023. Vous pouvez consulter les notes de session publique. L'équipe Chrome a également demandé des positions officielles de la part des deux fournisseurs concernant les normes. Consultez la section Liens associés. L'élément<permission>fait l'objet de discussions en cours avec d'autres navigateurs, et nous espérons le standardiser. - L'élément devrait-il être considéré comme vide ? La question de savoir si
<permission>doit être ou non un élément vide est toujours en cours de débat. Si vous avez des commentaires, intervenez au sujet du problème.
Liens associés
Remerciements
Ce document a été examiné par Balázs Engedy, Thomas Nguyen, Penelope McLachlan, Marian Harbach, David Warren et Rachel Andrew.