Publicado el 5 de febrero de 2025
A menos que se indique lo contrario, los siguientes cambios se aplican a la versión más reciente del canal beta de Chrome para Android, ChromeOS, Linux, macOS y Windows. Obtén más información sobre las funciones que se indican aquí a través de los vínculos proporcionados o de la lista en ChromeStatus.com. Chrome 134 es beta desde el 5 de febrero de 2025. Puedes descargar la versión más reciente en Google.com para computadoras o en Google Play Store para Android.
CSS
En esta versión, se agregan cinco funciones nuevas de CSS y de IU.
Propiedad dynamic-range-limit de CSS
Permite que una página limite el brillo máximo del contenido HDR.
Elemento <select> personalizable
Se agregó la capacidad de personalizar los elementos <select> de HTML. Para ello, habilita el nuevo comportamiento con el valor base-select de appearance. Después de habilitar la opción, puedes agregar contenido enriquecido, como imágenes, y también aplicar un estilo a las opciones.
Descarte ligero del diálogo
Una de las características interesantes de la API de Popover es su comportamiento de descarte ligero. Esta función brinda la misma capacidad a <dialog>. Un nuevo atributo closedby controla el comportamiento:
<dialog closedby=none>: No se cierran los diálogos activados por el usuario.<dialog closedby=closerequest>: Si se presionaESC(o cualquier otro activador de cierre), se cierra el diálogo.<dialog closedby=any>: Si haces clic fuera del diálogo o presionas ESC, se cierra el diálogo. Es igual que el comportamiento depopover=auto.
Herencia de CSS Highlight
Con la herencia de CSS Highlight, las seudoclases de CSS Highlight, como ::selection y ::highlight, heredan sus propiedades a través de la cadena de seudodestacado en vez de hacerlo a través de la cadena de elementos. El resultado es un modelo más intuitivo para la herencia de propiedades en elementos destacados.
Para obtener más información, lee la entrada de blog Cambios en la herencia para el diseño de la selección de CSS escrita por Stephen Chenney de Igalia.
Seudo-clase :has-slotted
La seudoclase :has-slotted representa un elemento de ranura con contenido insertado, como un nodo de texto o un elemento. Se puede usar para aplicar estilo a los elementos según si usan o no contenido de resguardo de ranura.
API web
Función de Attribution Reporting: Se quitó el límite de informes agregables cuando el ID del contexto del activador no es nulo
Este cambio se basa en los comentarios de quienes llaman a la API y en la necesidad de poder medir una mayor cantidad de eventos de conversión para ciertos flujos de usuarios.
Actualmente, la API tiene un límite que permite generar hasta 20 informes agregables por registro de fuente, lo que es restrictivo para los casos de uso en los que un usuario puede tener un recorrido más largo. Este cambio quita el límite de informes agregables cuando se proporciona un ID de contexto del activador como parte del registro. La eliminación de este límite se restringe solo a los casos en los que se especifica el ID del contexto del activador, ya que, cuando se especifica, la API aplica una tasa más alta de informes nulos, lo que ayuda a proteger contra la filtración de información entre sitios a través de los recuentos de informes.
Además, los informes agregables seguirán sujetos a otros límites que restringen la cantidad total de información que se puede medir, como el presupuesto de contribución de L1 (65,536) por fuente y el límite de frecuencia de atribución.
Partición de URLs de BLOB: recuperación y navegación
Como continuación de Storage Partitioning, se implementa la partición del acceso a URLs de BLOB por clave de almacenamiento (sitio de nivel superior, origen de marco y el booleano has-cross-site-ancestor), a excepción de las navegaciones de nivel superior que permanecerán particionadas solo por el origen del marco. Este comportamiento es similar al que implementan actualmente Firefox y Safari, y alinea el uso de la URL de BLOB con el esquema de partición que usan otras APIs de almacenamiento como parte de Storage Partitioning. Además, Chrome aplicará noopener en las navegaciones de nivel superior iniciadas por el renderizador a URLs de BLOB en las que el sitio correspondiente es un sitio cruzado con el sitio de nivel superior que realiza la navegación. Esto alinea a Chrome con un comportamiento similar en Safari, y las especificaciones pertinentes se actualizaron para reflejar estos cambios.
Para revertir este cambio temporalmente, establece la política PartitionedBlobURLUsage. La política dejará de estar disponible cuando se den de baja las otras políticas empresariales relacionadas con la partición de almacenamiento.
Document-Policy: expect-no-linked-resources
El punto de configuración expect-no-linked-resources en Document-Policy permite que un documento sugiera al agente de usuario que optimice mejor su secuencia de carga, por ejemplo, que no use el comportamiento de análisis especulativo predeterminado (también conocido como analizador de carga previa).
Los agentes de usuario implementaron el análisis especulativo de HTML para recuperar de forma especulativa los recursos presentes en el lenguaje de marcado HTML y, así, acelerar la carga de la página. Para la gran mayoría de las páginas de la Web que tienen recursos declarados en el lenguaje de marcado HTML, la optimización es beneficiosa y el costo que se paga para determinar esos recursos es una compensación adecuada. Sin embargo, las siguientes situaciones pueden generar una compensación de rendimiento subóptima en comparación con el tiempo explícito dedicado al análisis de HTML para determinar los recursos secundarios que se deben recuperar:
- Páginas que no tienen ningún recurso declarado en el HTML
- Páginas HTML grandes con cargas de recursos mínimas o nulas que podrían controlar explícitamente los recursos de precarga con otros mecanismos de precarga disponibles.
La directiva expect-no-linked-resources Document-Policy sugiere al agente de usuario que puede optar por optimizar el tiempo dedicado a determinar los recursos secundarios.
Administración explícita de recursos (síncrona y asíncrona)
Estas funciones abordan un patrón común en el desarrollo de software en relación con la vida útil y la administración de varios recursos (por ejemplo, la memoria y la E/S). Por lo general, este patrón incluye la asignación de un recurso y la capacidad de liberar de forma explícita los recursos críticos.
Extiende la API de console.timeStamp para admitir opciones de medición y presentación
Esta función extiende la API de console.timeStamp(), de una manera retrocompatible, para proporcionar un método de alto rendimiento para instrumentar aplicaciones y mostrar datos de sincronización en el panel Rendimiento de DevTools.
Las entradas de tiempo agregadas con la API pueden tener una marca de tiempo, una duración y opciones de presentación personalizadas (pista, carril y color).
OffscreenCanvas getContextAttributes
Agrega la interfaz getContextAttributes de CanvasRenderingContext2D a OffscreenCanvasRenderingContext2D.
API de Private Aggregation: Límites de contribución por contexto para quienes llaman a Shared Storage
Permite que los llamadores de Shared Storage personalicen la cantidad de contribuciones por informe de Private Aggregation.
Esta función permite que los llamadores de Shared Storage configuren límites de contribución por contexto con un nuevo campo, maxContributions. Las entidades que llaman establecen este campo para anular la cantidad predeterminada de contribuciones por informe. Se permitirán cantidades mayores y menores. Chrome aceptará valores de maxContributions entre 1 y 1,000 inclusive. Los valores más grandes se interpretarán como 1,000.
Debido al padding, el tamaño de la carga útil de cada informe será aproximadamente proporcional a la cantidad de contribuciones elegida por informe. Esperamos que habilitar informes más grandes aumente el costo de operar el Servicio de agregación.
Esta función no afectará a los llamadores de Protected Audience. Sin embargo, planeamos agregar compatibilidad para personalizar la cantidad de contribuciones de los informes de Protected Audience en funciones futuras.
Compatibilidad con ImageSmoothingQuality en PaintCanvas
Se agregó compatibilidad con el atributo imageSmoothingQuality en Paint Canvas. Permite que un desarrollador web elija la compensación entre calidad y rendimiento al cambiar el tamaño de las imágenes.
Hay tres opciones válidas para imageSmoothingQuality: low, medium y high.
Subgrupos de WebGPU
Se agrega la funcionalidad de subgrupos a WebGPU. Las operaciones de subgrupo realizan operaciones SIMT para proporcionar una comunicación y un uso compartido de datos eficientes entre grupos de invocaciones. Estas operaciones se pueden usar para acelerar las aplicaciones, ya que reducen la sobrecarga de memoria que genera la comunicación entre invocaciones.
Nuevas pruebas de origen
En Chrome 134, puedes habilitar las siguientes nuevas pruebas de origen.
API de Digital Credential
Actualmente, los sitios web pueden obtener credenciales de las apps de billetera para dispositivos móviles a través de diversos mecanismos, como los controladores de URLs personalizados y el escaneo de códigos QR. Esta función permite que los sitios soliciten información de identidad de las billeteras a través del sistema IdentityCredential CredMan de Android. Es extensible para admitir varios formatos de credenciales (por ejemplo, mDoc ISO y credenciales verificables de W3C) y permite usar varias apps de billetera. Se están agregando mecanismos para ayudar a reducir el riesgo de abuso a escala del ecosistema de la identidad del mundo real.
La prueba de origen que comienza en Chrome 134 agrega compatibilidad con esta API en la plataforma de escritorio, en la que Chrome en computadoras de escritorio se comunicará de forma segura con la billetera digital en el teléfono Android para recuperar las credenciales solicitadas.
Bajas y eliminaciones
En esta versión de Chrome, se introducen las bajas y eliminaciones que se indican a continuación. Visita ChromeStatus.com para ver listas de las bajas planificadas, las bajas actuales y las eliminaciones anteriores.
En esta versión de Chrome, se quita una función.
Se quitaron las restricciones de audio no estándar de getUserMedia
Blink admite una serie de restricciones no estándar con prefijo goog para getUserMedia desde un tiempo antes de que las restricciones se estandarizaran correctamente.
El uso disminuyó significativamente a entre el 0.000001% y el 0.0009% (según la restricción), y algunas de estas restricciones ni siquiera tienen un efecto debido a los cambios en la pila de captura de audio de Chromium. Pronto, ninguna de ellas tendrá efecto debido a otros cambios que realizaremos próximamente.
Esperamos que este cambio no genere regresiones importantes. Las aplicaciones que usen estas restricciones seguirán funcionando, pero obtendrán el audio con la configuración predeterminada (como si no se hubieran aplicado restricciones). Pueden optar por migrar a restricciones estándar.