Data di pubblicazione: 5 febbraio 2025
Se non diversamente specificato, 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 su 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 <select> HTML attivando il nuovo
comportamento con il base-select valore di appearance. Dopo aver attivato questa opzione, puoi aggiungere contenuti avanzati, incluse le immagini, e anche applicare uno stile alle opzioni.
Chiusura leggera della finestra di dialogo
Una delle funzionalità interessanti dell'API Popover è il comportamento di chiusura leggera. Questa
funzionalità porta 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>: la pressione diESC(o di un altro trigger di chiusura) chiude la finestra di dialogo.<dialog closedby=any>: se fai clic all'esterno della finestra di dialogo o premi ESC, la finestra di dialogo si chiude. Lo stesso comportamento dipopover=auto.
Ereditarietà degli elementi in evidenza del CSS
Con l'ereditarietà degli elementi in evidenza del CSS, le pseudo-classi di evidenziazione CSS, come ::selection e ::highlight, ereditano le loro proprietà tramite la catena di pseudo-evidenziazione, anziché la catena di elementi. Il risultato è un modello più intuitivo per l'ereditarietà delle proprietà negli elementi in evidenza.
Per saperne di più, leggi il post del blog Inheritance changes for CSS selection styling scritto da Stephen Chenney di Igalia.
Pseudo-classe :has-slotted
La pseudo-classe :has-slotted rappresenta un elemento slot con contenuti inseriti, ad esempio un nodo di testo o un elemento. Può essere utilizzata per applicare uno stile agli elementi in base al fatto che utilizzino o meno i contenuti di riserva dello slot.
API web
Funzionalità di report sull'attribuzione: rimozione del limite di report aggregabili quando l'ID contesto del trigger non è null
Questa modifica si basa sul feedback dei chiamanti dell'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 dell'origine, il che è restrittivo per i casi d'uso in cui un utente potrebbe avere un percorso utente più lungo. Questa modifica rimuove il limite di report aggregabili quando viene fornito un ID contesto del trigger come parte della registrazione. La rimozione di questo limite è limitata solo a quando viene specificato l'ID contesto del trigger, perché quando viene specificato l'API applica una percentuale più elevata di report null, il che contribuisce a proteggere dalla perdita di informazioni cross-site tramite i conteggi dei report.
Inoltre, i report aggregabili saranno comunque vincolati da altri limiti che limitano la quantità totale di informazioni che possono essere misurate, come il budget di contribuzione L1 (65.536) per origine e il limite di frequenza di attribuzione.
Partizionamento degli URL blob: recupero/navigazione
Come continuazione del partizionamento dello spazio di archiviazione, implementa il partizionamento dell'accesso agli URL blob in base alla chiave di archiviazione (sito di primo livello, origine del frame e il valore 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 di archiviazione 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 ripristinata temporaneamente 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 allo 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, al fine di 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 sostenuto per determinare queste risorse è un compromesso valido. Tuttavia, i seguenti scenari potrebbero comportare un compromesso di prestazioni non ottimale rispetto al tempo trascorso in modo esplicito per l'analisi dell'HTML per determinare le risorse secondarie da recuperare:
- Pagine che non hanno risorse dichiarate in HTML.
- Pagine HTML di grandi dimensioni con caricamenti di risorse minimi o nulli che potrebbero controllare in modo esplicito le risorse di precaricamento utilizzando altri meccanismi di precaricamento disponibili.
Il criterio Document-Policy expect-no-linked-resources suggerisce allo user agent di scegliere di ottimizzare il tempo trascorso per la determinazione di queste 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 include in genere l'allocazione di una risorsa e la possibilità di rilasciare in modo esplicito le risorse critiche.
Estensione dell'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 l'instrumentazione delle applicazioni e la visualizzazione dei dati di temporizzazione nel riquadro Rendimento di DevTools.
Le voci di temporizzazione aggiunte con l'API possono avere un timestamp, una durata e opzioni di presentazione personalizzate (traccia, swimlane e colore).
OffscreenCanvas getContextAttributes
Aggiunge l'interfaccia getContextAttributes da CanvasRenderingContext2D a
OffscreenCanvasRenderingContext2D.
API Private Aggregation: limiti di contribuzione per contesto per i chiamanti di Shared Storage
Consente ai chiamanti di Shared Storage di personalizzare il numero di contribuzioni per report di Private Aggregation.
Questa funzionalità consente ai chiamanti di Shared Storage di configurare i limiti di contribuzione per contesto con un nuovo campo, maxContributions. I chiamanti impostano questo campo per sostituire il numero predefinito di contribuzioni per report. Sono consentiti numeri maggiori e minori. Chrome accetterà valori di maxContributions compresi tra 1 e 1000 inclusi; i valori maggiori verranno interpretati come 1000.
A causa del padding, le dimensioni del payload di ogni report saranno approssimativamente proporzionali al numero di contribuzioni scelto per report. Prevediamo che l'attivazione di report più grandi aumenterà il costo di gestione del servizio di aggregazione.
Questa funzionalità non influirà sui chiamanti di Protected Audience. Tuttavia, stiamo pianificando di aggiungere il supporto per la personalizzazione del numero di contribuzioni per i report di Protected Audience nelle funzionalità future.
Supporto di ImageSmoothingQuality in PaintCanvas
Aggiungi il supporto per l'attributo imageSmoothingQuality su Paint Canvas. Consente a uno sviluppatore web di scegliere il compromesso tra qualità e prestazioni durante il ridimensionamento delle immagini.
Sono disponibili tre opzioni valide per imageSmoothingQuality: low, medium e high.
Gruppi secondari WebGPU
Aggiunge la funzionalità di sottogruppo a WebGPU. Le operazioni di sottogruppo eseguono operazioni SIMT per fornire una comunicazione e una condivisione dei dati efficienti tra i gruppi di chiamate. Queste operazioni possono essere utilizzate per accelerare le applicazioni riducendo i sovraccarichi di memoria causati dalla comunicazione tra le chiamate.
Nuove prove dell'origine
In Chrome 134 puoi attivare le seguenti nuove prove dell'origine.
API Digital Credential
Oggi i siti web possono ottenere 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 portafogli utilizzando il sistema IdentityCredential CredMan di Android. È estensibile per supportare più formati di credenziali (ad esempio, ISO mDoc e credenziali verificabili W3C) e consente di utilizzare più app di portafoglio. Vengono aggiunti meccanismi per contribuire a ridurre il rischio di abusi su scala dell'ecosistema dell'identità nel mondo reale.
La prova dell'origine a partire da Chrome 134 aggiunge il supporto per 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 dei ritiri pianificati, dei ritiri attuali e delle 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 fossero standardizzati correttamente.
L'utilizzo è diminuito in modo significativo, raggiungendo una percentuale compresa tra 0,000001% e 0,0009% (a seconda del vincolo) e alcuni di questi non hanno nemmeno un effetto a causa delle modifiche nello stack di acquisizione audio di Chromium. A breve nessuno di questi avrà alcun effetto a causa di altre modifiche imminenti.
Non prevediamo regressioni importanti a causa di questa modifica. Le applicazioni che utilizzano questi vincoli continueranno a funzionare, ma riceveranno l'audio con le impostazioni predefinite (come se non fossero stati passati vincoli). Possono scegliere di eseguire la migrazione ai vincoli standard.