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

Thomas Steiner

Esistono diversi metodi imperativi per chiedere l'autorizzazione all'utilizzo come l'accesso alla posizione nelle app web. Questi metodi prevedono diverse sfide, ed è per questo che il team delle autorizzazioni di Chrome sta sperimentando con un nuovo metodo dichiarativo: un elemento <permission> HTML dedicato. Questo è in versione di prova originale di Chrome 126, quindi speriamo di standardizzarla.

Metodi imperativi per richiedere l'autorizzazione

Quando le app web richiedono l'accesso a funzionalità molto utili, devono chiedere l'autorizzazione. Ad esempio, quando Google Maps richiede la posizione dell'utente utilizzando API Geolocation, browser chiederà all'utente, spesso con la possibilità di memorizzare tale decisione. Si tratta di un concetto ben definito nella specifica delle autorizzazioni.

Richiesta implicita al primo utilizzo rispetto a una richiesta esplicita anticipata

L'API Geolocation è un'API potente che si basa sulla domanda implicita l'uso di questo approccio. Ad esempio, quando un'app chiama navigator.geolocation.getCurrentPosition() la richiesta di autorizzazione viene visualizzata automaticamente alla prima chiamata. Un altro esempio è navigator.mediaDevices.getUserMedia()

Altre API, come API di notifica o il API Device Orientation e Motion, di solito hanno un modo esplicito per richiedere l'autorizzazione tramite un metodo statico come Notification.requestPermission() o DeviceMotionEvent.requestPermission()

Sfide con metodi imperativi per chiedere l'autorizzazione

Spam di autorizzazioni

In passato, i siti web richiamavano metodi come navigator.mediaDevices.getUserMedia() o Notification.requestPermission(), ma anche navigator.geolocation.getCurrentPosition() subito quando un sito web è stato caricato. Viene visualizzato un messaggio di autorizzazione prima che l'utente avesse interagito con del sito web. Talvolta è descritta come spam di autorizzazioni e interessa sia che richiede implicitamente al primo utilizzo e richiede esplicitamente 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 pulsante o un evento keydown prima di visualizzare la richiesta di autorizzazione. Il problema con questo approccio è che è molto difficile, se non impossibile, per il browser capire se un determinato gesto dell'utente deve comportare la richiesta di autorizzazione mostrati o meno. Forse l'utente ha fatto clic sulla pagina in frustrazione da qualche parte perché il caricamento della pagina ha richiesto molto tempo o forse facendo clic sul pulsante Trovami. Alcuni siti web sono diventati molto bravi anche in indurre con l'inganno gli utenti a fare clic sui contenuti per attivare la richiesta.

Un'altra mitigazione è l'aggiunta di mitigazioni rapide per gli abusi, come il blocco completo o mostrare la richiesta di autorizzazione in una modalità non modale, in modo invasivo.

Contestualizzazione autorizzazioni

Un'altra sfida, soprattutto sugli schermi di casa, è il modo in cui il prompt di autorizzazione viene visualizzato spesso: il limite della morte, ovvero fuori dall'area della finestra del browser su cui può essere visualizzata l'app. È se non conoscete che gli utenti potrebbero perdersi la richiesta nella parte superiore del browser. quando hanno fatto clic su un pulsante in fondo alla finestra. Questo problema è spesso esacerbato quando vengono applicate misure di mitigazione allo spam del browser.

Nessun annullamento facile

Infine, è troppo facile per gli utenti muoversi in una strada senza uscita. Per Ad esempio, una volta bloccato l'accesso a una funzionalità, è necessario che del menu a discesa delle informazioni sul sito in cui possono Reimpostare autorizzazioni o riattiva le autorizzazioni bloccate. Entrambe le opzioni nel peggiore richiede il ricaricamento completo della pagina finché non viene applicata l'impostazione aggiornata. I siti non possono fornire agli utenti una semplice scorciatoia per modificare di autorizzazione esistente e di spiegare scrupolosamente agli utenti come modificare le relative impostazioni come mostrato in fondo all'elenco di Google Maps screenshot.

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

Un elemento <permission> dichiarativo

Per risolvere le sfide descritte in questo post, il team delle autorizzazioni di Chrome hanno avviato una prova dell'origine di un nuovo elemento HTML, <permission>. Questo consente agli sviluppatori di chiedere 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, usalo come nell'esempio seguente:

<permission type="camera" />

È ancora dibattuto attivamente se <permission> deve essere nulla o meno. Un elemento vuoto è un elemento HTML che si chiude automaticamente avere nodi figlio, perciò in HTML potrebbe non avere un tag di fine.

Attributo type

La type contiene un elenco di autorizzazioni che stai richiedendo, separate da spazi. Alle ore 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 esegue il rendering in modo simile ai pulsanti con uno stile essenziale dello user agent.

Attributo type-ext

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

Attributo lang

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

Comportamento

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

• Se non avevano mai consentito una funzionalità, potrebbero consentirla a ogni visita oppure per la visita in corso.

  

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

  

• Se in precedenza aveva disattivato una funzionalità, può continuare a non consentirla, oppure consentilo questa volta.

  

Il testo dell'elemento <permission> si aggiorna automaticamente in base al . Ad esempio, se è stata concessa l'autorizzazione per utilizzare una caratteristica, il testo che la funzionalità è consentita. Se devi prima concedere l'autorizzazione, il testo cambia per invitare l'utente a utilizzare la funzionalità. Confronta i precedenti fai uno screenshot con il seguente per vedere i due stati.

Progettazione CSS

Per fare in modo che gli utenti possano riconoscere facilmente il pulsante come una piattaforma per accedere a potenti funzionalità, lo stile dell'elemento <permission> è limitato. Se lo stile non funzionano per il tuo caso d'uso, ci piacerebbe saperne di più come e perché! Anche se non è possibile soddisfare tutte le esigenze di stile, speriamo di poter scopri modi sicuri per concedere più stili all'elemento <permission> dopo il tag dell'origine dati. La tabella seguente descrive in dettaglio alcune strutture con limitazioni o regole speciali applicate. In caso di violazione di una qualsiasi delle regole, L'elemento <permission> verrà disattivato e non sarà possibile interagire. Qualsiasi tenta di interagire, daranno luogo a eccezioni che possono essere intercettate JavaScript. Il messaggio di errore conterrà ulteriori dettagli sui per violazione delle norme.

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 border-* proprietà)
• 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-* (con l'eccezione indicata in precedenza per 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

Inoltre, è possibile utilizzare tutte le proprietà logicamente equivalenti (ad esempio, inline-size equivale a width), che segue le stesse regole equivalenti.

Pseudo-classi

Esistono due pseudo-classi speciali che consentono di definire lo stile <permission> in base allo stato:

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

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> deve essere utilizzato insieme API Autorizzazioni. Esistono diversi eventi che possono essere ascoltati:

• onpromptdismiss: questo evento viene attivato quando la richiesta di autorizzazione viene attivata da l'elemento è stato ignorato dall'utente (ad esempio facendo clic sul pulsante o facendo clic all'esterno della richiesta).

• onpromptaction: questo evento viene attivato quando la richiesta di autorizzazione viene attivata da l'elemento sia stato risolto dall'utente che esegue un'azione sulla richiesta per trovare le regole. Ciò non significa necessariamente che lo stato di autorizzazione sia cambiato, l'utente potrebbe aver intrapreso un'azione che mantiene lo status quo (ad esempio, continuando a consentire un'autorizzazione).

• onvalidationstatuschange: questo evento viene attivato quando l'elemento passa da con un valore da "valid" a "invalid". L'elemento è considerato "valid" quando l'elemento il browser si fida dell'integrità dell'indicatore se l'utente fa clic e "invalid" altrimenti, ad esempio, quando l'elemento è parzialmente occulto dallo e altri contenuti HTML.

Puoi registrare listener di eventi per questi eventi direttamente inline nel codice HTML codice (<permission type="…" onpromptdismiss="alert('The prompt was dismissed');" />), oppure utilizzando addEventListener() sull'elemento <permission>, come mostrato in dall'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 delle caratteristiche

Se un browser non supporta un elemento HTML, non verrà visualizzato. Ciò significa che se nel codice HTML è presente l'elemento <permission>, non succede nulla se o un browser che non lo sa. Potresti comunque voler rilevare l'assistenza tramite JavaScript, Ad esempio, per creare una richiesta di autorizzazione attivata con un clic normale <button>.

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

Prova dell'origine

Per provare l'elemento <permission> sul tuo sito con utenti reali, registrarsi alla prova dell'origine. Leggi la guida introduttiva alle prove dell'origine per istruzioni su come preparare il tuo sito all'utilizzo delle prove dell'origine. La prova dell'origine verranno eseguite dalla versione 126 alla versione 131 di Chrome (19 febbraio 2025).

Demo

Esplora la demo e controlla il codice sorgente su GitHub. Ecco uno screenshot dell'esperienza su un browser di supporto.

Feedback

Ci piacerebbe conoscere la tua opinione su come funziona <permission> per il tuo caso d'uso. Sentire di rispondere a uno dei Problemi nel repository o invia una nuova notifica uno. Indicatori pubblici nel repository per il L'elemento <permission> comunicherà a noi e agli altri browser il tuo interesse li annotino.

Domande frequenti

• In che modo questo risultato è migliore rispetto a un normale <button> abbinato alle autorizzazioni dell'API? Il clic su <button> è un gesto dell'utente, ma i browser non hanno modo di verificando che sia collegato alla richiesta di autorizzazione. Se utente ha fatto clic su <permission>, il browser può essere certo che il clic sia relative a una richiesta di autorizzazione. Ciò consente al browser di facilitare i flussi altrimenti sarebbe molto più rischioso. Ad esempio, consentire all'utente di annullare facilmente il blocco di un'autorizzazione.
• Che cosa succede se gli altri browser non supportano l'elemento <permission>? La L'elemento <permission> può essere utilizzato come miglioramento progressivo. Attivato browser non supportati, è possibile usare un flusso di autorizzazioni classico. Ad esempio: in base al clic di un normale <button>. Anche il team responsabile delle autorizzazioni lavorando su un polyfill. Aggiungi a Speciali il repository GitHub per ricevere una notifica quando sarà pronto.
• La sessione è stata discussa con altri fornitori di browser? L'elemento <permission> discusso attivamente al W3C TPAC del 2023 in un del gruppo di lavoro. Tu possono leggere note pubbliche sulla sessione. Il team di Chrome ha anche chiesto posizioni standard per gli standard dei fornitori, consulta la sezione Link correlati. <permission> è un argomento di discussione costante con altri browser e stiamo sperando di standardizzarla.
• Questo elemento dovrebbe davvero essere vuoto? È ancora in corso dibattito attivo se <permission> deve essere nulla o meno. Se hai feedback, intervieni sulla questione.

Link correlati

• Spiegazione
• Posizione degli standard WebKit
• Posizione degli standard di Mozilla

Ringraziamenti

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