In quasi ogni versione di Chrome notiamo un numero significativo di aggiornamenti e miglioramenti al prodotto, alle sue prestazioni e anche alle funzionalità della piattaforma web.
In Chrome 49 (beta, 2 febbraio 2016. Data di stabilità stimata: marzo 2016) sono state apportate una serie di modifiche a Chrome
L'utilizzo del prefisso "css" in getComputedStyle(e).cssX è deprecato
TL;DR: l'uso del prefisso "css" in getComputedStyle(e) è stato deprecato poiché non faceva parte delle spec formali.
getComputedStyle è una piccola funzione eccezionale. Restituisce tutti i valori CSS degli stili dell'elemento DOM così come sono stati calcolati dal motore di rendering. Ad esempio, potresti eseguire getComputedStyle(_someElement_).height che potrebbe restituire 224,1 px perché questa è l'altezza dell'elemento così come viene visualizzato al momento.
Sembra un'API piuttosto utile. Cosa stiamo cambiando?
Prima che il motore di rendering di Chrome passasse a Blink, era basato su
WebKit e consentiva di anteporre "css" all'inizio di una proprietà. Ad
esempio getComputedStyle(e).cssHeight anziché getComputedStyle(e).height.
Entrambi restituiranno gli stessi dati mappati agli stessi valori sottostanti, ma è questo utilizzo del prefisso "css" non standard ed è stato ritirato e rimosso.
Nota: cssFloat è una proprietà standard e non è interessata da questo ritiro.
Se accedi a una proprietà in questo modo in Chrome 49, verrà restituito undefined e dovrai correggere il codice.
L'utilizzo di initTouchEvent è deprecato
TL;DR:
initTouchEvent
è stato deprecato a favore di
TouchEvent
constructor per migliorare la conformità alle specifiche e sarà rimosso del tutto in Chrome 54.
Intent di rimozione Tracker di stato di Chrome Problema CRBug
Per molto tempo sei in grado di creare eventi di tocco sintetici in Chrome
utilizzando l'API initTouchEvent; questi vengono spesso utilizzati per simulare eventi di tocco
per testare o automatizzare alcune UI nel tuo sito. Abbiamo ritirato questa API in Chrome 49 e mostreremo il seguente avviso con l'intenzione di rimuoverla completamente in Chrome 53.
Esistono diversi motivi per cui questa modifica è positiva.
Inoltre, non rientra nelle specifiche degli eventi touch. L'implementazione di initTouchEvent in Chrome non era affatto compatibile con l'API initTouchEvent di Safari ed era diversa da quella di Firefox su Android. Infine, il costruttore TouchEvent
è molto più facile da usare.
È stato deciso che il nostro obiettivo è seguire le specifiche piuttosto che mantenere un'API
che non sia specifica né compatibile con l'unica altra implementazione.
Di conseguenza, stiamo prima ritirando e poi rimuovendo la funzione initTouchEvent e chiedendo agli sviluppatori di utilizzare il costruttore TouchEvent.
Questa API viene utilizzata sul web, ma sappiamo che viene utilizzata da un numero relativamente basso di siti, quindi non la rimuoviamo così velocemente come potremmo normalmente. Riteniamo che una parte dell'utilizzo non sia disponibile a causa di siti che non gestiscono la versione della firma di Chrome.
Le implementazioni dell'API initTouchEvent per iOS e Android/Chrome
erano talmente diverse che spesso avresti un codice simile a (spesso dimenticando Firefox)
var event = document.createEvent('TouchEvent');
if(ua === 'Android') {
event.initTouchEvent(touchItem, touchItem, touchItem, "touchstart", window,
300, 300, 200, 200, false, false, false, false);
} else {
event.initTouchEvent("touchstart", false, false, window, 0, 300, 300, 200,
200, false, false, false, false, touches, targetTouches, changedTouches, 0, 0);
}
document.body.dispatchEvent(touchEvent);
Innanzitutto, questo è un problema, perché cerca "Android" nello user agent e Chrome su Android corrisponderà e verrà ritirato. Non può essere ancora rimosso, ma perché su Android ci saranno altri WebKit e browser meno recenti basati su Blink che dovranno ancora supportare l'API precedente.
Per gestire correttamente TouchEvents sul Web, devi modificare il tuo codice per supportare Firefox, IE Edge e Chrome verificando l'esistenza di TouchEvent nell'oggetto window e se ha una "lunghezza" positiva (indicando che si tratta di un costruttore che accetta un argomento), dovresti usarla.
if('TouchEvent' in window && TouchEvent.length > 0) {
var touch = new Touch({
identifier: 42,
target: document.body,
clientX: 200,
clientY: 200,
screenX: 300,
screenY: 300,
pageX: 200,
pageY: 200,
radiusX: 5,
radiusY: 5
});
event = new TouchEvent("touchstart", {
cancelable: true,
bubbles: true,
touches: [touch],
targetTouches: [touch],
changedTouches: [touch]
});
}
else {
event = document.createEvent('TouchEvent');
if(ua === 'Android') {
event.initTouchEvent(touchItem, touchItem, touchItem, "touchstart", window,
300, 300, 200, 200, false, false, false, false);
} else {
event.initTouchEvent("touchstart", false, false, window, 0, 300, 300, 200,
200, false, false, false, false, touches, targetTouches,
changedTouches, 0, 0);
}
}
document.body.dispatchEvent(touchEvent);
Gestori di errori e successi obbligatori nei metodi RTCPeerConnection
TL;DR: i metodi WebRTC
RTCPeerConnection createOffer()
e createAnswer()
ora richiedono un gestore degli errori oltre a un gestore del successo. In precedenza era possibile
chiamare questi metodi solo con un gestore dei successi. Questo utilizzo è obsoleto.
In Chrome 49 abbiamo anche aggiunto un avviso se chiami
setLocalDescription()
o setRemoteDescription()
senza fornire un gestore degli errori. Prevediamo di rendere obbligatorio l'argomento del gestore
degli errori per questi metodi in Chrome 50.
Ciò consente di fare promesse per questi metodi, come richiesto dalle specifiche WebRTC.
Ecco un esempio tratto dalla demo di una connessione RTCPeerConnection su WebRTC (main.js, riga 126):
function onCreateOfferSuccess(desc) {
pc1.setLocalDescription(desc, function() {
onSetLocalSuccess(pc1);
}, onSetSessionDescriptionError);
pc2.setRemoteDescription(desc, function() {
onSetRemoteSuccess(pc2);
}, onSetSessionDescriptionError);
pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
}
Tieni presente che setLocalDescription() e setRemoteDescription() hanno sempre avuto un parametro per il gestore degli errori, quindi specificare semplicemente tale parametro è una modifica sicura.
In generale, per le applicazioni WebRTC di produzione consigliamo di utilizzare adapter.js, uno shim gestito dal progetto WebRTC, per isolare le app dalle modifiche alle specifiche e dalle differenze nei prefissi.
Il file Document.defaultCharset è deprecato
TL;DR: Document.defaultCharset è stato deprecato per migliorare la conformità delle specifiche.
Intent di rimozione Tracker di stato di Chrome Problema CRBug
Document.defaultCharset è una proprietà di sola lettura che restituisce la codifica dei caratteri predefinita del sistema dell'utente in base alle impostazioni regionali. Non
è stato trovato utile mantenere questo valore a causa del modo in cui i browser utilizzano le informazioni sulla codifica dei caratteri nella risposta HTTP o nel meta tag incorporato nella pagina.
Utilizzando document.characterSet ottieni il primo valore specificato nell'intestazione HTTP. Se non è presente, verrà visualizzato il valore specificato
nell'attributo charset dell'elemento <meta> (ad esempio, <meta charset="utf-8">).
Infine, se nessuno di questi elementi è disponibile, document.characterSet corrisponderà all'impostazione di sistema dell'utente.
Gecko non ha supportato questa proprietà e non è specificata in modo pulito, pertanto verrà ritirata da Blink in Chrome 49 (beta a gennaio 2016). Il seguente avviso verrà visualizzato nella tua console fino alla rimozione della proprietà in Chrome 50:
Ulteriori informazioni sul ragionamento per non specificarlo possono essere lette su github. https://github.com/whatwg/dom/issues/58
Funzione getStorageUpdates() rimossa
TL;DR: Navigator.getStorageUpdates() è stato rimosso in quanto non è più incluso nelle specifiche del navigatore.
Intent di rimozione Tracker di stato di Chrome Problema CRBug
Se questo è un problema per qualcuno, mi mangio il cappello. getStorageUpdates() non è stato usato quasi mai sul web, se non del tutto.
Per citare la (versione molto vecchia) della specifica HTML5:
Sembra interessante, vero? La specifica utilizza persino la parola "whence" (che per caso è l'unica istanza di origine nella specifica). A livello di specifica, c'era un StorageMutex che controllava l'accesso allo spazio di archiviazione di blocco come
localStorage e i cookie e questa API avrebbe contribuito a liberare il mutex in modo che altri script non venissero bloccati da questo StorageMutex. Ma non è mai stato implementato, non è supportato in IE o Gecko e l'implementazione di WebKit (e quindi di Blink) è stata no-op.
È stata rimossa dalle specifiche per un po' di tempo ed è stata rimossa completamente da Blink (per molto tempo è stata nulla e non ha fatto nulla, anche se chiamata).
Nell'improbabile caso che tu abbia un codice che chiama navigator.getStorageUpdates(),
devi verificare la presenza della funzione prima di chiamarla.
Object.observe() è deprecato
TL;DR: Object.observe() è stato deprecato in quanto non è più nel canale di standardizzazione e verrà rimosso in una release futura.
Intent di rimozione Tracker di stato di Chrome Problema CRBug
Nel novembre 2015 è stato annunciato il ritiro di Object.Observe da TC39. È stato ritirato da Chrome 49 e se provi a utilizzarlo verrà visualizzato il seguente avviso nella console:
Molti sviluppatori hanno apprezzato questa API e, se l'hai sperimentata e ora stai cercando un percorso di transizione, valuta l'utilizzo di un polyfill come MaxArt2501/object-observe o una libreria di wrapping come polymer/observe-js.