Existen varios métodos imperativos para solicitar permiso de uso.
funciones potentes como el acceso a la ubicación en las aplicaciones web. Estos métodos incluyen un
de desafíos, por lo que el equipo de permisos de Chrome está experimentando
con un nuevo método declarativo: un elemento HTML <permission>
dedicado. Esta
está en prueba de origen para Chrome 126 y, en última instancia, esperamos
estandarizarlos.
Métodos imperativos para solicitar permiso
Cuando las aplicaciones web necesitan acceder a funciones potentes, tendrás que pedir permiso. Por ejemplo, cuando Google Maps requiere la ubicación del usuario mediante el API de Geolocation, los navegadores le solicitarán al usuario la opción de almacenar esa decisión. Este es un concepto bien definido en la especificación de permisos.
Pregunta de forma implícita en el primer uso en lugar de una solicitud explícita por adelantado
La API de Geolocation es una API potente y se basa en la solicitud implícita de la primera
enfoque de uso. Por ejemplo, cuando una aplicación llama a
navigator.geolocation.getCurrentPosition()
, la solicitud de permisos aparece automáticamente en la primera llamada.
Otro ejemplo es
navigator.mediaDevices.getUserMedia()
Otras APIs, como la
API de notificación o
el
API de Device Orientation y Motion,
suelen tener una forma explícita de solicitar permisos a través de un método estático, como
Notification.requestPermission()
o
DeviceMotionEvent.requestPermission()
Desafíos relacionados con los métodos imperativos para solicitar permisos
Spam de permisos
Antes, los sitios web podían llamar a métodos como
navigator.mediaDevices.getUserMedia()
o Notification.requestPermission()
,
sino también navigator.geolocation.getCurrentPosition()
de inmediato
se cargó. Aparecerá un mensaje de solicitud de permiso antes de que el usuario haya interactuado.
del sitio web. Esto a veces se describe como spam de permisos y afecta
que solicitan de forma implícita la primera vez que se usa, así como
por adelantado.
Mitigaciones del navegador y requisito de gestos del usuario
Spam de permisos llevó a que los proveedores de navegadores requiriesen un gesto del usuario como un botón clic o un evento keydown antes de mostrar un mensaje de permiso. El problema con este enfoque es que es muy difícil, sino imposible, que el navegador averiguar si un determinado gesto del usuario debe dar como resultado una solicitud de permiso mostrar o no. Tal vez el usuario solo estaba haciendo clic en la página frustrado. en cualquier lugar porque la página tardó demasiado en cargarse, o tal vez debido a haciendo clic en el botón Ubicarme. Algunos sitios web también se volvieron muy buenos engañar a los usuarios para que hagan clic en el contenido a fin de activar el mensaje.
Otra mitigación es agregar mitigaciones rápidas de los abusos, como bloquear por completo comenzar o mostrar la solicitud de permiso de forma no modal, de forma invasiva.
Contexto de permisos
Otro desafío, especialmente en las pantallas grandes, es la forma en que la solicitud de permiso se muestra comúnmente: arriba del línea de la muerte, esa fuera del área de la ventana del navegador en la que la app puede dibujar. Es que los usuarios se perderían el mensaje en la parte superior de su navegador cuando hacen clic en un botón de la parte inferior. Este problema se ve agravada cuando se implementan las mitigaciones de spam en los navegadores.
No es fácil deshacer
Por último, es demasiado fácil para los usuarios dirigirse a un callejón sin salida. Para ejemplo, una vez que el usuario bloquea el acceso a una función, esta deberá estar al tanto del menú desplegable de información del sitio donde puede Restablecer permisos o volver a activar los permisos bloqueados. En el peor de los casos, ambas opciones requieren una recarga completa de la página hasta que se aplique la configuración actualizada. Los sitios no pueden ofrecer a los usuarios un acceso directo sencillo para cambiar un estado de permiso existente y deben explicar minuciosamente a los usuarios cómo cambian sus parámetros de configuración como se muestra en la parte inferior de los siguientes mapas de Google Maps captura de pantalla.
Si el permiso es clave para la experiencia, por ejemplo, el acceso al micrófono para una aplicación de videoconferencia, las apps como Google Meet muestran diálogos intrusivos que le indican al usuario cómo desbloquear el permiso.
Un elemento <permission>
declarativo
Para abordar los desafíos descritos en esta publicación, el equipo de permisos de Chrome
lanzaron una prueba de origen para un nuevo elemento HTML, <permission>
. Esta
permite a los desarrolladores solicitar permiso de forma declarativa para usar, por ahora, un
un subconjunto de las funciones potentes disponibles para los sitios web. En su forma más sencilla,
utilízalo como en el siguiente ejemplo:
<permission type="camera" />
Todavía se debate activamente
si <permission>
debe ser inexistente
o no. Un elemento vacío es un elemento de cierre automático en HTML que no puede
tener nodos secundarios, lo que, en HTML, significa que es posible que no tenga una etiqueta de cierre.
El atributo type
El
type
contiene una lista separada por espacios de los permisos que solicitas. En
al momento de esta escritura, los valores permitidos son 'camera'
, 'microphone'
y
camera microphone
(separados por espacios). Este elemento se renderiza de forma predeterminada.
similares a los botones con diseños de usuario-agente simples.
El atributo type-ext
En el caso de algunos permisos que permiten parámetros adicionales, la
type-ext
acepta pares clave-valor separados por espacios, por ejemplo,
precise:true
para el permiso de ubicación geográfica.
El atributo lang
El navegador proporciona el texto del botón
para que sea coherente.
no se pueden personalizar directamente. El navegador cambia el idioma del texto.
según el idioma heredado del documento o de la cadena de elementos superiores
de manera opcional
lang
. Esto significa que los desarrolladores no necesitan localizar el <permission>
elemento en sí. Si el elemento <permission>
procede más allá del origen
de prueba, se pueden admitir varias cadenas o íconos para cada tipo de permiso
para aumentar la flexibilidad. Si te interesa usar <permission>
y necesitas una cadena o un ícono específico, comunícate con nosotros.
Comportamiento
Cuando el usuario interactúa con el elemento <permission>
, puede recorrer
en varias etapas:
Si no habían permitido una función antes, pueden hacerlo en cada visita. permitirlo para la visita actual.
Si ya habían permitido la función antes, pueden seguir haciéndolo o dejar de hacerlo permitiéndolo.
Si anteriormente inhabilitaron una función, pueden seguir no habilitándola. pero esta vez.
El texto del elemento <permission>
se actualiza automáticamente según la
estado. Por ejemplo, si se otorgó permiso para usar un atributo, el texto
cambios para indicar que el componente está permitido. Si primero se debe otorgar el permiso,
el texto cambia para invitar al usuario a usar la función. Comparar los anteriores
con la siguiente captura de pantalla para ver los dos estados.
Diseño de CSS
Para garantizar que los usuarios puedan reconocer fácilmente el botón como una superficie para acceder
, se restringe el diseño del elemento <permission>
. Si el estilo
no funcionan para tu caso de uso, nos encantaría conocer
cómo y por qué. Si bien no es posible satisfacer todas las necesidades de diseño, esperamos
descubrir formas seguras de permitir más estilos del elemento <permission>
después del
prueba de origen. En la siguiente tabla, se detallan algunas propiedades que tienen restricciones
o reglas especiales que se les aplican. En caso de que se incumpla alguna de las reglas, el
Se inhabilitará <permission>
elemento y no se podrá interactuar con él. Cualquiera
intentos de interactuar con ella generará excepciones que pueden detectarse con
JavaScript: El mensaje de error contendrá más detalles sobre el
incumplimiento.
Propiedad | Reglas |
---|---|
|
Se puede usar para establecer el color del texto y del fondo, respectivamente. El el contraste entre los dos colores debe ser suficiente para que texto legible (relación de contraste de al menos 3). El canal alfa debe sea 1. |
|
Se debe establecer dentro del equivalente de small y
xxxlarge De lo contrario, se inhabilitará el elemento. Acercar
se tendrá en cuenta cuando se calcule font-size . |
|
Los valores negativos se corregirán a 0 . |
margin (todos) |
Los valores negativos se corregirán a 0 . |
|
Los valores inferiores a 200 se corregirán a 200 . |
|
Los valores distintos de normal y italic serán
corregido a normal |
|
Los valores superiores a 0.5em se corregirán a
0.5em Los valores inferiores a 0 se corregirán a
0 |
|
Valores distintos de inline-block y none
se corregirá a inline-block . |
|
Los valores superiores a 0.2em se corregirán a
0.2em Los valores inferiores a -0.05em serán
corregido a -0.05em |
|
Tendrá un valor predeterminado de 1em . Si se proporciona, el
valor máximo calculado entre los valores predeterminados y proporcionados
. |
|
Tendrá un valor predeterminado de 3em . Si se proporciona, el
valor mínimo calculado entre los valores predeterminados y proporcionados
. |
|
Tendrá un valor predeterminado de fit-content . Si se proporciona,
el valor máximo calculado entre el valor predeterminado y el proporcionado
y valores. |
|
Tendrá un valor predeterminado de tres veces fit-content Si
proporcionado, el valor mínimo computado entre el valor predeterminado y
y los valores proporcionados. |
|
Solo tendrá efecto si se establece height como
auto En este caso, los valores superiores a 1em serán
se corrigió a 1em , y la padding-bottom será
Se establece en el valor de padding-top . |
|
Solo tendrá efecto si se establece width como
auto En este caso, los valores superiores a 5em serán
se corrigió a 5em , y la padding-right será
configurado en el valor de padding-left. |
|
No se permitirá distorsionar los efectos visuales. Por ahora, solo aceptar traslación en 2D y aumento proporcional. |
Las siguientes propiedades de CSS se pueden usar con normalidad:
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
(y todas las propiedades deborder-*
)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 la excepción indicada anteriormente paraoutline-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
Además, se pueden usar todas las propiedades equivalentes a la lógica (por ejemplo,
inline-size
equivale a width
) y sigue las mismas reglas que su
equivalente.
Pseudoclases
Existen dos seudoclases especiales que permiten aplicar diseño a <permission>
.
según el estado:
:granted
: La seudoclase:granted
permite un estilo especial cuando un elemento se otorgó el permiso.:invalid
: La seudoclase:invalid
permite un estilo especial cuando la elemento tiene un estado no válido, por ejemplo, cuando se entrega en una iframe de origen cruzado.
permission {
background-color: green;
}
permission:granted {
background-color: light-green;
}
/* Not supported during the origin trial. */
permission:invalid {
background-color: gray;
}
Eventos de JavaScript
El elemento <permission>
está diseñado para usarse junto con el
API de Permissions:
Se pueden escuchar varios eventos:
onpromptdismiss
: Este evento se activa cuando la solicitud de permiso activada por El usuario descartó el elemento (por ejemplo, al hacer clic en el botón o haciendo clic fuera del mensaje).onpromptaction
: Este evento se activa cuando la solicitud de permiso activada por Cuando el usuario realiza alguna acción en el mensaje, resuelve el elemento a sí mismo. Esto no significa necesariamente que haya cambiado el estado del permiso, usuario podría haber realizado una acción que mantiene el statu quo (como seguir otorgando un permiso).onvalidationstatuschange
: Este evento se activa cuando el elemento cambia de es de"valid"
a"invalid"
. El elemento se considera"valid"
cuando la El navegador confía en la integridad de la señal si el usuario hace clic en ella."invalid"
de lo contrario, por ejemplo, cuando el elemento esté parcialmente ocluido por otro contenido HTML.
Puedes registrar objetos de escucha de eventos para estos eventos directamente intercalados en el código HTML.
código
(<permission type="…" onpromptdismiss="alert('The prompt was dismissed');" />
),
o usando addEventListener()
en el elemento <permission>
, como se muestra en la
siguiente ejemplo.
<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>
Detección de funciones
Si un navegador no es compatible con un elemento HTML, no lo mostrará. Esto significa que
si tienes el elemento <permission>
en tu código HTML, no sucede nada si el elemento
el navegador no lo sabe. Puede que quieras seguir
detectando compatibilidad con JavaScript
por ejemplo, para crear una solicitud de permiso que se active mediante un clic en un
<button>
normal.
if ('HTMLPermissionElement' in window) {
// The `<permission>` element is supported.
}
Prueba de origen
Para probar el elemento <permission>
en tu sitio con usuarios reales,
registrarte en la prueba de origen.
Lee Comienza a usar las pruebas de origen para
instrucciones sobre cómo preparar tu sitio para usar pruebas de origen. La prueba de origen
se ejecutará de la versión 126 a la 131 de Chrome (19 de febrero de 2025).
Demostración
Explora la demostración y revisa el código fuente en GitHub. A continuación, se muestra una captura de pantalla de la experiencia en un navegador compatible.
Comentarios
Nos encantaría saber cómo funciona <permission>
en tu caso de uso. Siente
libre de responder a uno de los
Problemas en el repositorio o envía un archivo nuevo
uno. Los indicadores públicos en el repositorio para el
El elemento <permission>
nos permitirá a nosotros y a otros navegadores saber que te interesa
que la modifica.
Preguntas frecuentes
- ¿En qué es mejor que un
<button>
normal vinculado con los permisos API? Un clic en un<button>
es un gesto del usuario, pero los navegadores no tienen forma de lo que verifica que está conectado a la solicitud para pedir permiso. Si el botón si un usuario hizo clic en un<permission>
, el navegador puede estar seguro de que el clic relacionadas con una solicitud de permiso. Esto permite que el navegador facilite los flujos que, de otro modo, sería mucho más arriesgado. Por ejemplo, permitir que el usuario deshacer fácilmente el bloqueo de un permiso. - ¿Qué sucede si otros navegadores no admiten el elemento
<permission>
? El El elemento<permission>
se puede usar como mejora progresiva. Activada navegadores no compatibles, se puede usar un flujo de permisos clásico. Por ejemplo: según el clic de un<button>
normal. El equipo de permisos también trabajando con un polyfill. Destaca el repositorio de GitHub. para recibir una notificación cuando esté listo. - ¿Se analizó esto con otros proveedores de navegadores? El elemento
<permission>
se discutió activamente en el W3C TPAC en 2023 en un sesión separada. Tú pueden leer el notas de la sesión pública. El equipo de Chrome también solicitó posiciones formales de Estándares a ambos, consulte la sección Vínculos relacionados. El<permission>
es un tema de debate constante con otros navegadores, y con el objetivo de estandarizarlo. - ¿Debería ser un elemento vacío? Todavía se está
debatir activamente
si
<permission>
debe ser inexistente o no. Si tienes comentarios, informa sobre el problema.
Vínculos relacionados
Agradecimientos
Este documento fue revisado por Balázs Engedy, Thomas Nguyen: Penelope McLachlan, Marian Harbach David Warren y Rachel Andrew.