Fecha de publicación: 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 enumeran aquí a través de los vínculos proporcionados o en la lista de ChromeStatus.com. Chrome 134 es una versión beta a partir del 5 de febrero de 2025. Puedes descargar la versión más reciente en Google.com para computadoras de escritorio o en Google Play Store para Android.
CSS
Esta versión agrega cinco nuevas funciones de CSS y IU.
Propiedad dynamic-range-limit de CSS
Permite que una página limite el brillo máximo del contenido HDR.
Elemento <select> personalizable
Agrega la capacidad de personalizar los elementos <select> de HTML habilitando el nuevo comportamiento con el valor base-select de appearance. Después de habilitar esta opción, puedes agregar contenido enriquecido, incluidas imágenes, y aplicarles un diseño a las opciones.
Descartar la luz del diálogo
Una de las funciones 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 presionasESC(o algún otro activador de cierre), se cerrará el diálogo.<dialog closedby=any>: Si haces clic fuera del diálogo o presionas ESC, se cerrará. Es igual que el comportamiento depopover=auto.
Herencia de elementos destacados de CSS
Con la herencia de CSS Highlight, las seudoclases de ese elemento, 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 Inheritance changes for CSS selection styling , escrita por Stephen Chenney de Igalia.
Pseudoclase :has-slotted
La pseudoclase :has-slotted representa un elemento de ranura con contenido en la ranura, como un nodo o elemento de texto. Esto se puede usar para aplicar diseño a los elementos según si usan o no contenido de resguardo de la posición.
API web
Función de informes de atribución: Se quitó el límite de informes agregables cuando el ID de contexto del activador no es nulo.
Este cambio se basa en los comentarios de los llamadores de 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 del usuario 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 cuando se especifica el ID de 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 porcentaje de atribución.
Partición de URLs de BLOB: recuperación o navegación
Como continuación de Storage Partitioning, implementa la partición del acceso a la URL 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 Chrome con un comportamiento similar en Safari, y las especificaciones relevantes 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 le sugiera al usuario-agente que optimice mejor su secuencia de carga, por ejemplo,
no usar el comportamiento de análisis especulativo predeterminado (también conocido como escáner de carga previa).
Los agentes de usuario implementaron el análisis especulativo de HTML para recuperar de forma especulativa los recursos que están presentes en el marcado HTML y acelerar la carga de la página. Para la gran mayoría de las páginas en la Web que tienen recursos declarados en el marcado HTML, la optimización es beneficiosa y el costo pagado para determinar esos recursos es una compensación sólida. Sin embargo, las siguientes situaciones pueden generar un rendimiento poco óptimo en comparación con el tiempo explícito que se dedica a analizar el código HTML para determinar los subrecursos que se deben recuperar:
- Son páginas que no tienen ningún recurso declarado en el código HTML.
- Páginas HTML grandes con cargas de recursos mínimas o sin ellas que podrían controlar de forma explícita los recursos de carga previa con otros mecanismos de carga previa disponibles
La política de documentos expect-no-linked-resources le sugiere al usuario-agente que puede optar por optimizar el tiempo dedicado a esa determinación de subrecursos.
Administración de recursos explícita (asíncrona y síncrona)
Estas funciones abordan un patrón común en el desarrollo de software en relación con el tiempo de vida y la administración de varios recursos (por ejemplo, memoria y E/S). Por lo general, este patrón incluye la asignación de un recurso y la capacidad de liberar recursos críticos de forma explícita.
Se extendió la API de console.timeStamp para admitir opciones de medición y presentación
Esta función extiende la API de console.timeStamp() de manera retrocompatible para proporcionar un método de alto rendimiento para instrumentar aplicaciones y mostrar datos de tiempo en el panel Rendimiento en DevTools.
Las entradas de tiempos que se agregan con la API pueden tener una marca de tiempo personalizada, duración y opciones de presentación (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 los llamadores de Shared Storage
Permite que los llamadores de almacenamiento compartido personalicen la cantidad de contribuciones por informe de agregación privada.
Esta función permite que los llamadores de almacenamiento compartido configuren límites de contribución por contexto con un campo nuevo, maxContributions. Los llamadores establecen este campo para anular la cantidad predeterminada de contribuciones por informe. Se permitirán números más grandes y más pequeños. 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 elegidas por informe. Esperamos que habilitar informes más grandes aumente el costo de operar el servicio de agregación.
Los llamadores de Protected Audience no se verán afectados por esta función. 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 calidad en lugar del rendimiento cuando se escalan las imágenes.
Existen tres opciones válidas para imageSmoothingQuality: low, medium y high.
Subgrupos de WebGPU
Se agregó la funcionalidad de subgrupos a WebGPU. Las operaciones de subgrupo realizan operaciones de 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 pruebas de origen nuevas.
API de Digital Credential
Actualmente, los sitios web pueden obtener credenciales de las apps de billetera para dispositivos móviles a través de una variedad de mecanismos, por ejemplo, controladores de URL personalizados y escaneo de códigos QR. Esta función permite que los sitios soliciten información de identidad a las billeteras con el sistema CredMan de IdentityCredential de Android. Es extensible para admitir varios formatos de credenciales (por ejemplo, mDoc ISO y credencial verificable del W3C) y permite usar varias apps de billetera. Se están agregando mecanismos para ayudar a reducir el riesgo de abuso de identidad del mundo real a escala del ecosistema.
La prueba de origen que comienza en Chrome 134 agrega compatibilidad con esta API en la plataforma para computadoras, en la que Chrome para computadoras se comunicará de forma segura con la billetera digital en el teléfono Android para recuperar las credenciales solicitadas.
Bajas y eliminaciones
Esta versión de Chrome presenta las bajas y las eliminaciones que se indican a continuación. Visita ChromeStatus.com para ver las listas de bajas planificadas, las bajas actuales y las eliminaciones anteriores.
Esta versión de Chrome 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 un 0.000001% y un 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, ninguno de ellas tendrá efecto debido a otros cambios que realizaremos próximamente.
No esperamos que este cambio genere regresiones importantes. Las aplicaciones que usen estas restricciones seguirán funcionando, pero obtendrán audio con la configuración predeterminada (como si no se hubieran pasado restricciones). Pueden optar por migrar a restricciones estándar.