Phase d'évaluation pour un nouvel élément HTML "permission>"

Thomas Steiner

Il existe plusieurs méthodes impératives pour demander l'autorisation d'utiliser des fonctionnalités puissantes telles que l'accès aux données de localisation dans les applications Web. Ces méthodes présentent un certain nombre de défis. C'est pourquoi l'équipe chargée des autorisations Chrome teste une nouvelle méthode déclarative : un élément HTML <permission> dédié. Cet élément est en phase d'évaluation depuis Chrome 126, et nous espérons finalement le normaliser.

Méthodes impératives pour demander une autorisation

Lorsque les applications Web ont besoin d'accéder à des fonctionnalités puissantes, elles doivent demander l'autorisation. Par exemple, lorsque Google Maps nécessite la position de l'utilisateur à l'aide de l'API Geolocation, les navigateurs invitent 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 lors de la première utilisation ou demander explicitement dès le départ

L'API Geolocation est une API puissante qui s'appuie sur l'approche d'interrogation implicite lors de la 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. Voici un autre exemple : navigator.mediaDevices.getUserMedia().

D'autres API, comme l'API Notification ou l'API Device Orientation and Motion, proposent généralement un moyen explicite de demander une autorisation via une méthode statique telle que Notification.requestPermission() ou DeviceMotionEvent.requestPermission().

Difficultés liées aux méthodes impératives de demande d'autorisation

Spam d'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 lors du chargement d'un site Web. Une invite d'autorisation s'affiche avant que l'utilisateur n'interagisse avec le site Web. Ce phénomène est parfois décrit comme du spam d'autorisation et affecte les deux approches, à la fois lors de la première utilisation et lors de la demande explicite.

Mesures d'atténuation dans le navigateur et exigences concernant les gestes utilisateur

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 utilisateur donné doit entraîner l'affichage d'une invite d'autorisation ou non. L'utilisateur a peut-être simplement cliqué n'importe où sur la page par frustration, car le chargement a été très long, ou il a peut-être effectivement cliqué 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 solution consiste à ajouter des mesures d'atténuation des abus des requêtes, comme le blocage complet des fonctionnalités au départ ou l'affichage de la requête 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 est généralement affichée: au-dessus de la ligne de la mort, c'est-à-dire en dehors de la zone de la fenêtre du navigateur sur laquelle l'application peut dessiner. Il n'est pas rare que les utilisateurs ne voient pas l'invite en haut de la fenêtre de leur navigateur lorsqu'ils viennent de cliquer sur un bouton en bas de la fenêtre. Ce problème est souvent exacerbé lorsque des mesures d'atténuation du spam sont mises en place dans le navigateur.

Impossible d'annuler facilement

Enfin, il est trop facile pour les utilisateurs de se retrouver dans une impasse. Par exemple, une fois que l'utilisateur a bloqué l'accès à une fonctionnalité, il doit connaître le menu déroulant des informations sur le site, où 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 un raccourci simple permettant aux utilisateurs de modifier un état d'autorisation existant. Ils doivent expliquer minutieusement aux utilisateurs 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, des applications comme Google Meet affichent des boîtes de dialogue intrusives qui indiquent à l'utilisateur comment débloquer l'autorisation.

Élément <permission> déclaratif

Pour résoudre les problèmes décrits dans cet article, l'équipe chargée des autorisations Chrome a lancé un test d'origine 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, pour le moment, un sous-ensemble des fonctionnalités puissantes 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 un élément vide ou non fait toujours l'objet d'un débat actif. 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 cet article, les valeurs autorisées sont 'camera', 'microphone' et camera microphone (séparées par un espace). Par défaut, cet élément se présente comme des boutons avec un style d'agent utilisateur basique.

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 des espaces, 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'essai d'origine, 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'a pas autorisé une fonctionnalité auparavant, il peut l'autoriser à chaque visite ou pour la visite en cours.

  

• S'il avait déjà autorisé la fonctionnalité, il peut continuer à l'autoriser ou l'arrêter.

  

• S'il avait précédemment refusé une fonctionnalité, il peut continuer à la refuser ou l'autoriser cette fois.

  

Le texte de l'élément <permission> est automatiquement mis à jour en fonction de l'état. Par exemple, si une autorisation a été accordée pour utiliser une fonctionnalité, le texte indique que la fonctionnalité est autorisée. Si une 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 à des fonctionnalités puissantes, le style de l'élément <permission> est limité. Si les restrictions de style ne conviennent pas à votre cas d'utilisation, n'hésitez pas à nous en faire part. Bien que tous les besoins de stylisation ne puissent pas être satisfaits, nous espérons trouver des moyens sûrs d'autoriser davantage de stylisation de l'élément <permission> après l'essai d'origine. 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> est désactivé et ne peut pas être utilisé. Toute tentative d'interaction avec ce fichier entraînera des exceptions qui pourront être interceptées par JavaScript. Le message d'erreur contient plus d'informations sur l'infraction détectée.

Les propriétés CSS suivantes peuvent être utilisées normalement:

• 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 (et toutes les propriétés border-*)
• 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-* (à l'exception de outline-offset mentionnée précédemment)
• 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

De plus, toutes les propriétés logiquement équivalentes peuvent être utilisées (par exemple, inline-size est équivalent à width), en suivant les mêmes règles que leur équivalent.

Pseudo-classes

Il existe deux pseudo-classes spéciales qui permettent de styliser l'élément <permission> en fonction de l'état:

• :granted: la pseudo-classe :granted permet d'appliquer un style spécial lorsqu'une autorisation a été accordée.
• :invalid: la pseudo-classe :invalid permet d'appliquer un style spécial lorsque l'élément est dans un état non valide, par exemple lorsqu'il est diffusé dans un iframe inter-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. Plusieurs événements peuvent être écoutés:

• onpromptdismiss: cet événement se déclenche lorsque l'utilisateur a ignoré l'invite d'autorisation déclenchée par l'élément (par exemple, en cliquant sur le bouton de fermeture ou en cliquant en dehors de l'invite).

• onpromptaction: cet événement se déclenche lorsque l'utilisateur a résolu l'invite d'autorisation déclenchée par l'élément en effectuant une action sur l'invite elle-même. 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 à autoriser 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 comme "invalid" dans le cas contraire, par exemple lorsque l'élément est partiellement masqué par un autre contenu HTML.

Vous pouvez enregistrer des écouteurs d'événements pour ces événements directement dans le code HTML (<permission type="…" onpromptdismiss="alert('The prompt was dismissed');" />) ou à l'aide de 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 fonctionnalités

Si un navigateur n'accepte pas un élément HTML, il ne l'affichera pas. Cela signifie que si vous avez l'élément <permission> dans votre code HTML, rien ne se passe si le navigateur ne le connaît pas. Vous pouvez 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.
}

Essai Origin

Pour tester l'élément <permission> sur votre site avec de vrais utilisateurs, inscrivez-vous au test de l'origine. Pour savoir comment préparer votre site à utiliser les essais d'origine, consultez Premiers pas avec les essais d'origine. La phase d'évaluation de l'origine s'étendra de Chrome 126 à Chrome 131 (19 février 2025).

Démo

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 du dépôt de l'élément <permission> nous indiqueront, ainsi qu'aux autres navigateurs, que vous êtes intéressé par cet élément.

Questions fréquentes

• En quoi est-ce mieux 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'autorisation 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 de discussions actives lors du TPAC du W3C en 2023, lors d'une session de travail. Vous pouvez consulter les notes de session publique. L'équipe Chrome a également demandé aux deux fournisseurs de fournir une position officielle sur les normes. Consultez la section Liens associés. L'élément <permission> fait l'objet de discussions continues avec d'autres navigateurs, et nous espérons le normaliser.
• Doit-il s'agir d'un élément vide ? Il est toujours actuellement débattu si <permission> doit être un élément vide ou non. Si vous avez des commentaires, n'hésitez pas à les partager.

Liens associés

• Explication
• Position de WebKit concernant les normes
• Position de Mozilla sur les normes

Remerciements

Ce document a été examiné par Balázs Engedy, Thomas Nguyen, Penelope McLachlan, Marian Harbach, David Warren et Rachel Andrew.