Data di pubblicazione: 5 febbraio 2025
Se non diversamente indicato, le seguenti modifiche si applicano alla versione più recente del canale beta di Chrome per Android, ChromeOS, Linux, macOS e Windows. Scopri di più sulle funzionalità elencate qui tramite i link forniti o dall'elenco su ChromeStatus.com. Chrome 134 è in versione beta dal 5 febbraio 2025. Puoi scaricare l'ultima versione su Google.com per computer o sul Google Play Store su Android.
CSS
Questa release aggiunge cinque nuove funzionalità CSS e UI.
Proprietà CSS dynamic-range-limit
Consente a una pagina di limitare la luminosità massima dei contenuti HDR.
Elemento <select> personalizzabile
Aggiungi la possibilità di personalizzare gli elementi HTML <select> attivando il nuovo
comportamento con il valore base-select di appearance. Dopo l'attivazione, puoi
aggiungere contenuti avanzati, incluse le immagini, e anche personalizzare lo stile delle opzioni.
Chiudi la finestra di dialogo
Una delle funzionalità più interessanti dell'API Popover è il comportamento di chiusura leggera. Questa
funzionalità offre la stessa funzionalità a <dialog>. Un nuovo attributo closedby
controlla il comportamento:
<dialog closedby=none>: nessuna chiusura delle finestre di dialogo attivata dall'utente.<dialog closedby=closerequest>: se premiESC(o un altro trigger di chiusura), la finestra di dialogo si chiude.<dialog closedby=any>: se fai clic all'esterno della finestra di dialogo o premi Esc, la finestra di dialogo si chiude. Uguale al comportamento dipopover=auto.
Ereditarietà degli elementi in evidenza del CSS
Con l'ereditarietà dell'evidenziazione CSS, le pseudo-classi di evidenziazione CSS, come
::selection e ::highlight, ereditano le proprietà tramite la catena di pseudo-evidenziazione, anziché la catena di elementi. Il risultato è un modello più intuitivo
per l'ereditarietà delle proprietà nei punti salienti.
Per saperne di più, leggi il post del blog Inheritance changes for CSS selection styling scritto da Stephen Chenney di Igalia.
:has-slotted pseudo-classe
La pseudo-classe :has-slotted rappresenta un elemento slot con contenuti inseriti, ad esempio un nodo di testo o un elemento. Può essere utilizzato per applicare uno stile agli elementi in base
al fatto che utilizzino o meno i contenuti di riserva dello slot.
API web
Funzionalità di generazione di report sull'attribuzione: rimozione del limite dei report aggregabili quando l'ID contesto trigger non è nullo
Questa modifica si basa sul feedback dei chiamanti API e sulla necessità di poter misurare un numero maggiore di eventi di conversione per determinati flussi utente.
Attualmente, l'API ha un limite che consente di generare fino a 20 report aggregabili per registrazione della sorgente, il che è restrittivo per i casi d'uso in cui un utente potrebbe avere un percorso più lungo. Questa modifica rimuove il limite dei report aggregabili quando viene fornito un ID contesto attivatore nell'ambito della registrazione. La rimozione di questo limite è limitata solo ai casi in cui viene specificato l'ID contesto del trigger, perché quando viene specificato l'API applica una percentuale più elevata di report nulli, il che contribuisce a proteggere dalla divulgazione di informazioni cross-site tramite i conteggi dei report.
Inoltre, i report aggregabili saranno comunque vincolati da altri limiti che restringono la quantità totale di informazioni che possono essere misurate, come il budget di contributo L1 (65.536) per origine e il limite di frequenza dell'attribuzione.
Partizionamento dell'URL blob: recupero/navigazione
Come continuazione del partizionamento dello spazio di archiviazione, implementa il partizionamento dell'accesso all'URL blob tramite la chiave di archiviazione (sito di primo livello, origine del frame e booleano has-cross-site-ancestor), ad eccezione delle navigazioni di primo livello che rimarranno partizionate solo in base all'origine del frame. Questo comportamento è simile a quello attualmente implementato da Firefox e Safari e allinea l'utilizzo degli URL Blob allo schema di partizionamento utilizzato da altre API Storage nell'ambito del partizionamento dello spazio di archiviazione. Inoltre, Chrome applicherà noopener alle navigazioni di primo livello avviate dal renderer agli URL blob in cui il sito corrispondente è cross-site rispetto al sito di primo livello che esegue la navigazione. In questo modo, Chrome si allinea a un comportamento simile in Safari e le specifiche pertinenti sono state aggiornate per riflettere queste modifiche.
Questa modifica può essere temporaneamente annullata impostando il criterio PartitionedBlobURLUsage. Il criterio verrà ritirato quando verranno ritirati gli altri criteri aziendali
correlati al partizionamento dello spazio di archiviazione.
Document-Policy: expect-no-linked-resources
Il punto di configurazione expect-no-linked-resources in Document-Policy consente a un documento di suggerire all'user agent di ottimizzare meglio la sequenza di caricamento, ad esempio di non utilizzare il comportamento di analisi speculativa predefinito (noto anche come scanner di precaricamento).
Gli user agent hanno implementato l'analisi speculativa dell'HTML per recuperare in modo speculativo le risorse presenti nel markup HTML, in modo da velocizzare il caricamento della pagina. Per la stragrande maggioranza delle pagine web che hanno risorse dichiarate nel markup HTML, l'ottimizzazione è vantaggiosa e il costo pagato per determinare tali risorse è un compromesso valido. Tuttavia, gli scenari seguenti potrebbero comportare un compromesso di rendimento non ottimale rispetto al tempo trascorso esplicitamente nell'analisi HTML per determinare le risorse secondarie da recuperare:
- Pagine in cui non sono dichiarate risorse nell'HTML.
- Pagine HTML di grandi dimensioni con caricamenti di risorse minimi o nulli che potrebbero controllare esplicitamente il precaricamento delle risorse utilizzando altri meccanismi di precaricamento disponibili.
expect-no-linked-resources Document-Policy suggerisce allo user agent che
può scegliere di ottimizzare il tempo trascorso in questa determinazione delle risorse secondarie.
Gestione esplicita delle risorse (asincrona e sincrona)
Queste funzionalità riguardano un pattern comune nello sviluppo software relativo alla durata e alla gestione di varie risorse (ad esempio memoria e I/O). Questo pattern in genere include l'allocazione di una risorsa e la possibilità di rilasciare esplicitamente le risorse critiche.
Estendere l'API console.timeStamp per supportare le opzioni di misurazione e presentazione
Questa funzionalità estende l'API console.timeStamp(), in modo retrocompatibile, per fornire un metodo ad alte prestazioni per instrumentare le applicazioni e
mostrare i dati di temporizzazione nel riquadro Prestazioni di DevTools.
Le voci di sincronizzazione aggiunte con l'API possono avere un timestamp, una durata e opzioni di presentazione personalizzati (traccia, corsia e colore).
OffscreenCanvas getContextAttributes
Aggiunge l'interfaccia getContextAttributes da CanvasRenderingContext2D a
OffscreenCanvasRenderingContext2D.
API Private Aggregation: limiti di contributo per contesto per i chiamanti di Shared Storage
Consente ai chiamanti di Shared Storage di personalizzare il numero di contributi per report Private Aggregation.
Questa funzionalità consente ai chiamanti di Shared Storage di configurare limiti di contributo per contesto con un nuovo campo, maxContributions. I chiamanti impostano questo campo
per ignorare il numero predefinito di contributi per report. Saranno consentiti numeri
più grandi e più piccoli. Chrome accetterà valori di maxContributions
compresi tra 1 e 1000 inclusi; i valori più grandi verranno interpretati come 1000.
A causa del padding, le dimensioni del payload di ogni report saranno proporzionali al numero di contributi scelto per report. Prevediamo che l'attivazione di report più grandi aumenterà il costo di gestione del servizio di aggregazione.
I chiamanti Protected Audience non saranno interessati da questa funzionalità. Tuttavia, stiamo pianificando di aggiungere il supporto per la personalizzazione del numero di contributi per i report Protected Audience nelle funzionalità future.
Supporto di ImageSmoothingQuality in PaintCanvas
Aggiungi il supporto per l'attributo imageSmoothingQuality in Paint Canvas. Consente
a uno sviluppatore web di scegliere il compromesso tra qualità e prestazioni durante il ridimensionamento delle immagini.
Esistono tre opzioni valide per imageSmoothingQuality: low, medium e
high.
Sottogruppi WebGPU
Aggiunge la funzionalità di sottogruppo a WebGPU. Le operazioni sui sottogruppi eseguono operazioni SIMT per fornire una comunicazione e una condivisione dei dati efficienti tra gruppi di invocazioni. Queste operazioni possono essere utilizzate per accelerare le applicazioni riducendo i sovraccarichi di memoria causati dalla comunicazione tra le invocazioni.
Nuove prove dell'origine
In Chrome 134 puoi attivare le seguenti nuove prove dell'origine.
API Digital Credential
I siti web possono ottenere e ottengono le credenziali dalle app di portafoglio mobile tramite una serie di
meccanismi, ad esempio gestori di URL personalizzati e scansione di codici QR. Questa
funzionalità consente ai siti di richiedere informazioni sull'identità dai wallet utilizzando il sistema
IdentityCredential CredMan di Android. È estensibile per supportare più
formati di credenziali (ad esempio ISO mDoc e credenziali verificabili W3C) e
consente l'utilizzo di più app per il portafoglio. Stiamo aggiungendo meccanismi per contribuire a ridurre il rischio di abusi su larga scala dell'identità reale.
La prova dell'origine a partire da Chrome 134 aggiunge il supporto di questa API sulla piattaforma desktop, dove Chrome su computer comunicherà in modo sicuro con il portafoglio digitale sullo smartphone Android per recuperare le credenziali richieste.
Ritiri e rimozioni
Questa versione di Chrome introduce i ritiri e le rimozioni elencati di seguito. Visita ChromeStatus.com per visualizzare gli elenchi di ritiri pianificati, ritiri attuali e rimozioni precedenti.
Questa release di Chrome rimuove una funzionalità.
Rimozione dei vincoli audio non standard di getUserMedia
Blink supporta una serie di vincoli non standard con prefisso goog per
getUserMedia da un po' di tempo prima che i vincoli venissero standardizzati correttamente.
L'utilizzo è diminuito in modo significativo, attestandosi tra lo 0,000001% e lo 0,0009% (a seconda del vincolo) e alcuni di questi non hanno nemmeno effetto a causa delle modifiche apportate allo stack di acquisizione audio di Chromium. A breve nessuna di queste avrà effetto a causa di altre modifiche imminenti.
Non prevediamo regressioni significative a causa di questa modifica. Le applicazioni che utilizzano questi vincoli continueranno a funzionare, ma l'audio verrà riprodotto con le impostazioni predefinite (come se non fossero stati passati vincoli). Possono scegliere di eseguire la migrazione ai vincoli standard.