Una prova dell'origine per un nuovo elemento HTML <permission>

Thomas Steiner

Esistono diversi metodi imperativi per chiedere l'autorizzazione a utilizzare funzionalità efficaci come l'accesso alla posizione nelle app web. Questi metodi presentano una serie di problematiche, ed è per questo che il team delle autorizzazioni di Chrome sta sperimentando un nuovo metodo dichiarativo: un elemento <permission> HTML dedicato. Questo elemento è in prova di origine da Chrome 126 e, in definitiva, prevediamo di standardizzarlo.

Metodi imperativi per richiedere l'autorizzazione

Quando le app web hanno bisogno di accedere a funzionalità avanzate, devono chiedere l'autorizzazione. Ad esempio, quando Google Maps richiede la posizione dell'utente utilizzando l'API Geolocation, i browser chiederanno all'utente, spesso con la possibilità di memorizzare la decisione. Si tratta di un concetto ben definito nella specifica delle autorizzazioni.

Richiesta implicita al primo utilizzo o richiesta esplicita anticipata

L'API Geolocation è un'API potente e si basa sull'approccio di richiesta implicita al primo uso. Ad esempio, quando un'app chiama il metodo navigator.geolocation.getCurrentPosition(), la richiesta di autorizzazione viene visualizzata automaticamente alla prima chiamata. Un altro esempio è navigator.mediaDevices.getUserMedia().

Altre API, come l'API Notification o l'API Device Orientation and Motion, hanno in genere un modo esplicito per richiedere l'autorizzazione tramite un metodo statico come Notification.requestPermission() o DeviceMotionEvent.requestPermission().

Problemi con i metodi imperativi per chiedere l'autorizzazione

Spam per le autorizzazioni

In passato, i siti web potevano chiamare metodi come navigator.mediaDevices.getUserMedia() o Notification.requestPermission(), ma anche navigator.geolocation.getCurrentPosition() immediatamente al caricamento di un sito web. Prima che l'utente interagisse con il sito web, veniva visualizzata una richiesta di autorizzazione. A volte questo fenomeno è descritto come spam di autorizzazioni e interessa entrambi gli approcci, sia la richiesta implicita al primo utilizzo sia la richiesta esplicita in anticipo.

Mitigazioni del browser e requisito relativo ai gesti dell'utente

Lo spam di autorizzazioni ha portato i fornitori di browser a richiedere un gesto dell'utente, ad esempio un clic su un pulsante o un evento keydown, prima di mostrare una richiesta di autorizzazione. Il problema di questo approccio è che è molto difficile, se non impossibile, per il browser capire se un determinato gesto dell'utente deve comportare o meno la visualizzazione di una richiesta di autorizzazione. È possibile che l'utente abbia fatto clic sulla pagina in un punto qualsiasi per sfinimento perché il caricamento della pagina ha richiesto molto tempo oppure è possibile che abbia effettivamente fatto clic sul pulsante Trova la mia posizione. Inoltre, alcuni siti web sono diventati molto bravi a convincere gli utenti a fare clic sui contenuti per attivare la richiesta.

Un'altra soluzione è aggiungere mitigazioni per gli abusi dei prompt, ad esempio bloccare completamente le funzionalità all'inizio o mostrare la richiesta di autorizzazione in modo non modale e meno invadente.

Contestualizzazione delle autorizzazioni

Un'altra sfida, soprattutto sugli schermi di grandi dimensioni, è il modo in cui la richiesta di autorizzazione viene visualizzata comunemente: sopra la linea di morte, ovvero al di fuori dell'area della finestra del browser su cui l'app può attingere. Non è raro che gli utenti non vedano la richiesta nella parte superiore della finestra del browser dopo aver fatto clic su un pulsante nella parte inferiore della finestra. Questo problema si aggrava spesso quando sono attive le misure di mitigazione dello spam del browser.

Impossibile annullare facilmente

Infine, è troppo facile per gli utenti imbattersi in un vicolo cieco. Ad esempio, una volta che l'utente ha bloccato l'accesso a una funzionalità, è necessario essere a conoscenza del menu a discesa delle informazioni sul sito, dove può reimpostare le autorizzazioni o riattivare le autorizzazioni bloccate. Nel peggiore dei casi, entrambe le opzioni richiedono un ricaricamento completo della pagina fino a quando non viene applicata l'impostazione aggiornata. I siti non sono in grado di fornire una scorciatoia facile per consentire agli utenti di modificare uno stato di autorizzazione esistente e devono spiegare loro con fatica come modificare le impostazioni, come mostrato nella parte inferiore dello screenshot di Google Maps riportato di seguito.

Se l'autorizzazione è fondamentale per l'esperienza, ad esempio l'accesso al microfono per un'applicazione di videoconferenza, app come Google Meet mostrano finestre di dialogo invadenti che spiegano all'utente come sbloccare l'autorizzazione.

Un elemento <permission> dichiarativo

Per affrontare le sfide descritte in questo post, il team delle autorizzazioni di Chrome ha avviato una prova dell'origine per un nuovo elemento HTML, <permission>. Questo elemento consente agli sviluppatori di richiedere in modo dichiarativo l'autorizzazione a utilizzare, per il momento, un sottoinsieme delle potenti funzionalità disponibili per i siti web. Nella sua forma più semplice, lo utilizzi come nell'esempio seguente:

<permission type="camera" />

È ancora in discussione se <permission> debba essere un elemento vuoto o meno. Un elemento vuoto è un elemento HTML autochiudente che non può avere nodi secondari, il che significa che in HTML non può avere un tag di chiusura.

Attributo type

L'attributo type contiene un elenco delle autorizzazioni richieste separate da spazi. Al momento della stesura del presente documento, i valori consentiti sono 'camera', 'microphone' e camera microphone (separati da uno spazio). Per impostazione predefinita, questo elemento viene visualizzato in modo simile ai pulsanti con uno stile di user agent essenziale.

Attributo type-ext

Per alcune autorizzazioni che consentono parametri aggiuntivi, l'attributo type-ext accetta coppie chiave-valore separate da spazi, ad esempio precise:true per l'autorizzazione di geolocalizzazione.

Attributo lang

Il testo del pulsante è fornito dal browser e deve essere coerente, pertanto non può essere personalizzato direttamente. Il browser cambia la lingua del testo in base alla lingua ereditata del documento o della catena di elementi principali oppure a un attributo facoltativo lang. Ciò significa che gli sviluppatori non devono localizzare autonomamente l'elemento <permission>. Se l'elemento <permission> procede oltre la fase di prova dell'origine, potrebbero essere supportate diverse stringhe o icone per ogni tipo di autorizzazione per aumentare la flessibilità. Se ti interessa utilizzare l'elemento <permission> e hai bisogno di una stringa o un'icona specifica, contattaci.

Comportamento

Quando l'utente interagisce con l'elemento <permission>, può scorrere diverse fasi:

• Se non ha mai consentito una funzionalità, può farlo per ogni visita o solo per quella in corso.

  

• Se avevano già consentito la funzionalità, potranno continuare a consentirla o interromperla.

  

• Se in precedenza non aveva consentito una funzionalità, può continuare a non consentirla o consentirla questa volta.

  

Il testo dell'elemento <permission> si aggiorna automaticamente in base allo stato. Ad esempio, se è stata concessa l'autorizzazione per l'utilizzo di una funzionalità, il testo cambia per indicare che la funzionalità è consentita. Se devi prima concedere l'autorizzazione, il testo cambia per invitare l'utente a usare la funzionalità. Confronta lo screenshot precedente con quello seguente per vedere i due stati.

Design CSS

Per garantire che gli utenti possano riconoscere facilmente il pulsante come una piattaforma per accedere a funzionalità efficaci, lo stile dell'elemento <permission> è limitato. Se le limitazioni di stile non sono adatte al tuo caso d'uso, saremmo lieti di sapere come e perché. Sebbene non sia possibile soddisfare tutte le esigenze di stile, ci auguriamo di trovare modi sicuri per consentire un maggiore stile dell'elemento <permission> dopo la prova dell'origine. La tabella seguente descrive alcune proprietà a cui sono applicate limitazioni o regole speciali. Se una delle regole viene violata, l'elemento<permission> viene disattivato e non è possibile interagire con esso. Qualsiasi tentativo di interazione comporta eccezioni che possono essere rilevate con JavaScript. Il messaggio di errore conterrà ulteriori dettagli sulla violazione rilevata.

Le seguenti proprietà CSS possono essere utilizzate normalmente:

• 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 (e tutte le proprietà 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-* (tranne che per outline-offset, come indicato in precedenza)
• 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

Inoltre, è possibile utilizzare tutte le proprietà logicamente equivalenti (ad esempio, inline-size è equivalente a width), seguendo le stesse regole del loro equivalente.

Pseudo-classi

Esistono due pseudoclassi speciali che consentono di applicare stili all'elemento <permission> in base allo stato:

• :granted: la pseudo-classe :granted consente uno stile speciale quando è stata concessa un'autorizzazione.
• :invalid: la pseudo-classe :invalid consente di applicare stili speciali quando l'elemento è in uno stato non valido, ad esempio quando viene pubblicato in un iframe cross-origin.

permission {
  background-color: green;
}

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

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

Eventi JavaScript

L'elemento <permission> è progettato per essere utilizzato insieme all'API Permissions. Esistono diversi eventi che possono essere ascoltati:

• onpromptdismiss: questo evento viene attivato quando la richiesta di autorizzazione attivata dall'elemento è stata ignorata dall'utente (ad esempio facendo clic sul pulsante di chiusura o al di fuori della richiesta).

• onpromptaction: questo evento viene attivato quando la richiesta di autorizzazione attivata dall'elemento è stata risolta dall'utente che ha eseguito un'azione sulla richiesta stessa. Ciò non significa necessariamente che lo stato dell'autorizzazione sia cambiato, l'utente potrebbe aver intrapreso un'azione che mantiene lo status quo (ad esempio continuare a consentire un'autorizzazione).

• onvalidationstatuschange: questo evento viene attivato quando l'elemento passa da "valid" a "invalid". L'elemento viene considerato "valid" quando il browser ritiene attendibile l'integrità dell'indicatore se l'utente fa clic e "invalid" in caso contrario, ad esempio quando l'elemento è parzialmente occulto da altri contenuti HTML.

Puoi registrare gli ascoltatori di eventi per questi eventi direttamente in linea nel codice HTML (<permission type="…" onpromptdismiss="alert('The prompt was dismissed');" />), o utilizzando addEventListener() nell'elemento <permission>, come mostrato nell'esempio seguente.

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

Rilevamento di funzionalità

Se un browser non supporta un elemento HTML, non lo mostrerà. Ciò significa che se nel codice HTML è presente l'elemento <permission>, non succede nulla se il browser non lo conosce. Potresti comunque voler rilevare il supporto utilizzando JavaScript, ad esempio per creare una richiesta di autorizzazione attivata tramite un clic su un <button> normale.

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

Prova dell'origine

Per provare l'elemento <permission> sul tuo sito con utenti reali, registrati per la prova dell'origine. Leggi la pagina Inizia a utilizzare le prove dell'origine per istruzioni su come preparare il tuo sito all'utilizzo delle prove dell'origine. La prova dell'origine verrà eseguita da Chrome 126 a 131 (19 febbraio 2025).

Demo

Dai un'occhiata alla demo e controlla il codice sorgente su GitHub. Ecco uno screenshot dell'esperienza su un browser supportato.

Feedback

Ci piacerebbe conoscere la tua opinione su come <permission> funziona per il tuo caso d'uso. Non esitare a rispondere a uno dei problemi nel repository o a presentarne uno nuovo. Gli indicatori pubblici nel repo per l'elemento <permission> ci faranno sapere, a noi e ad altri browser, che ti interessa.

Domande frequenti

• In che modo è migliore di un normale <button> accoppiato con l'API Permissions? Un clic di <button> è un gesto dell'utente, ma i browser non hanno modo di verificare che sia connesso alla richiesta di richiesta di autorizzazione. Se l'utente ha fatto clic su un <permission>, il browser può essere certo che il clic sia correlato a una richiesta di autorizzazione. In questo modo il browser semplifica i flussi che altrimenti sarebbero molto più rischiosi. Ad esempio, consentire all'utente di annullare facilmente il blocco di un'autorizzazione.
• Cosa succede se altri browser non supportano l'elemento <permission>? L'elemento <permission> può essere utilizzato come miglioramento progressivo. Nei browser non supportati, è possibile utilizzare un flusso di autorizzazione classico. Ad esempio, in base al clic di un normale <button>. Il team responsabile delle autorizzazioni sta anche lavorando a un polyfill. Aggiungi il repo GitHub ai preferiti per ricevere una notifica quando sarà pronto.
• Questo problema è stato discusso con altri fornitori di browser? L'elemento <permission> è stato discusso attivamente al W3C TPAC nel 2023 in un gruppo di lavoro. Puoi leggere le note relative alle sessioni pubbliche. Il team di Chrome ha anche chiesto una posizione formale in merito agli standard a entrambi i fornitori. Consulta la sezione Link correlati. L'elemento <permission> è un argomento di discussione in corso con altri browser e ci auguriamo di standardizzarlo.
• Dovrebbe essere un elemento vuoto? È ancora in discussione se <permission> debba essere un elemento vuoto o meno. Se hai feedback, partecipa al problema.

Link correlati

• Spiegazione
• Posizione relativa agli standard WebKit
• Posizione di Mozilla in merito agli standard

Ringraziamenti

Questo documento è stato esaminato da Balázs Engedy, Thomas Nguyen, Penelope McLachlan, Marian Harbach, David Warren e Rachel Andrew.