In quasi tutte le versioni di Chrome vediamo un numero significativo di aggiornamenti e miglioramenti del prodotto, delle sue prestazioni e anche delle funzionalità della piattaforma web.
In Chrome 49 (beta del 2 febbraio 2016). Data di rilascio stimata della versione stabile: marzo 2016) sono state apportate diverse modifiche a Chrome
L'utilizzo del prefisso "css" in getComputedStyle(e).cssX è deprecato
TL;DR: l'utilizzo del prefisso "css" in
getComputedStyle(e)
è stato ritirato perché non faceva parte della
specifica formale.
getComputedStyle è una piccola funzione molto utile. 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 e potrebbe restituire 224,1 px perché questa è l'altezza dell'elemento così come viene visualizzato attualmente.
Sembra un'API piuttosto utile. Quindi, cosa cambierà?
Prima che il motore di rendering di Chrome passasse a Blink, era basato su
WebKit, che consentiva di aggiungere il prefisso "css" all'inizio di una proprietà. Ad esempio, getComputedStyle(e).cssHeight invece di getComputedStyle(e).height.
Entrambi restituirebbero gli stessi dati perché mappati sugli stessi valori sottostanti,
ma è questo utilizzo del prefisso "css" che non è standard, è 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
Riepilogo:
initTouchEvent
è stato ritirato a favore di
TouchEvent
constructor per migliorare
la conformità alle specifiche e verrà rimosso completamente in Chrome 54.
Intent to Remove Chromestatus Tracker CRBug Issue
Per molto tempo hai potuto creare eventi tocco sintetici in Chrome
utilizzando l'API initTouchEvent, che vengono spesso utilizzati per simulare eventi tocco
per testare o automatizzare alcune UI del tuo sito. In Chrome 49 abbiamo
deprecato questa API e verrà visualizzato il seguente avviso con l'intenzione
di rimuoverla completamente in Chrome 53.
Esistono diversi motivi per cui questa modifica è positiva.
Inoltre, non è presente nella specifica degli eventi tocco. L'implementazione di Chrome di
initTouchEvent non era compatibile con l'API initTouchEvent di Safari e
differiva da quella di Firefox su Android. Infine, il costruttore TouchEvent è molto più facile da usare.
È stato deciso di seguire la specifica anziché mantenere un'API
che non è specificata né compatibile con l'unica altra implementazione.
Di conseguenza, prima ritireremo e poi rimuoveremo la funzione initTouchEvent
e richiederemo agli sviluppatori di utilizzare il costruttore TouchEvent.
Esiste un utilizzo di questa API sul web, ma sappiamo che viene utilizzata da un numero relativamente basso di siti, quindi non la rimuoviamo così rapidamente come potremmo fare normalmente. Riteniamo che parte dell'utilizzo non funzioni a causa del fatto che i siti non gestiscono la versione della firma di Chrome.
Poiché le implementazioni iOS e Android/Chrome dell'API initTouchEvent
erano così diverse, spesso avevi del codice simile a (dimenticando spesso 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 raggiungerà questo ritiro. Non può ancora essere rimosso perché su Android saranno ancora presenti per un po' altri browser basati su WebKit e Blink meno recenti che dovranno ancora supportare l'API precedente.
Per gestire correttamente TouchEvents sul web, devi modificare il codice in modo da
supportare Firefox, IE Edge e Chrome controllando l'esistenza di TouchEvent
nell'oggetto window e, se ha una "lunghezza" positiva (a indicare che è un
costruttore che accetta un argomento), devi utilizzarlo.
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 richiesti nei metodi RTCPeerConnection
TL;DR: i metodi WebRTC
createOffer() e createAnswer()
ora richiedono un gestore degli errori e un gestore di successo. In precedenza era possibile chiamare questi metodi solo con un gestore di esito positivo. Questo utilizzo è
deprecato.
In Chrome 49 è stato aggiunto anche un avviso se chiami
setLocalDescription()
o setRemoteDescription()
senza fornire un gestore di errori. Prevediamo di rendere obbligatorio l'argomento del gestore degli errori
per questi metodi in Chrome 50.
Ciò fa parte della preparazione all'introduzione delle promesse in questi metodi, come richiesto dalla specifica WebRTC.
Ecco un esempio della demo RTCPeerConnection di 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 sia setLocalDescription() che setRemoteDescription() hanno sempre avuto un parametro
di gestione degli errori, quindi la semplice specifica di questo parametro è una modifica sicura.
In generale, per le applicazioni WebRTC di produzione consigliamo di utilizzare
adapter.js, un shim gestito dal
progetto WebRTC, per isolare le app dalle modifiche alle specifiche e dalle differenze di prefisso.
Document.defaultCharset è deprecato
TL;DR: Document.defaultCharset è stato ritirato per migliorare la conformità alle specifiche.
Intent to Remove Chromestatus Tracker CRBug Issue
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 ritenuto 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.
Se utilizzi document.characterSet, otterrai il primo valore specificato nell'intestazione HTTP. Se non è presente, verrà utilizzato il valore specificato nell'attributo
charset dell'elemento <meta> (ad esempio, <meta charset="utf-8">).
Infine, se nessuno di questi è disponibile, document.characterSet sarà l'impostazione di sistema dell'utente.
Gecko non ha mai supportato questa proprietà e non è specificata in modo chiaro, pertanto verrà ritirata da Blink in Chrome 49 (beta a gennaio 2016). Il seguente avviso verrà visualizzato nella console fino alla rimozione della proprietà in Chrome 50:
Puoi leggere ulteriori discussioni sul motivo per cui non specificare questo aspetto su GitHub https://github.com/whatwg/dom/issues/58
getStorageUpdates() rimosso
TL;DR: Navigator.getStorageUpdates() è stato rimosso perché non è più presente nella
specifica Navigator.
Intent to Remove Chromestatus Tracker CRBug Issue
Se questa modifica influirà su qualcuno, mi mangio il cappello. getStorageUpdates() non è quasi mai stato utilizzato sul web.
Per citare la (vecchissima) versione della specifica HTML5:
Sembra fantastico, vero? La specifica utilizza persino la parola "da dove" (che per
caso è l'unica istanza di "da dove" nella specifica). A livello di specifica
era presente un StorageMutex che controllava l'accesso allo spazio di archiviazione di blocco, ad esempio
localStorage e i cookie. Questa API avrebbe contribuito a liberare il mutex in modo che altri
script non venissero bloccati da questo StorageMutex. ma non è mai stata
implementata, non è supportata in IE o Gecko e l'implementazione di WebKit (e quindi di Blink)
è stata un'operazione nulla.
È stata rimossa dalle specifiche da un po' di tempo ed è stata rimossa completamente da Blink (per molto tempo non ha fatto nulla anche se chiamata).
Nel caso improbabile in cui tu abbia codice che chiama navigator.getStorageUpdates(),
dovrai verificare la presenza della funzione prima di chiamarla.
Object.observe() è deprecato
TL;DR: Object.observe() è stato ritirato perché non è più in fase di standardizzazione
e verrà rimosso in una release futura.
Intent to Remove Chromestatus Tracker CRBug Issue
A novembre 2015 è stato annunciato il ritiro di Object.Observe da TC39. È stato
ritirato da Chrome 49 e se provi a utilizzarlo, nella console
viene visualizzato il seguente avviso:
A molti sviluppatori è piaciuta questa API e, se l'hai sperimentata e ora stai cercando un percorso di transizione, valuta la possibilità di utilizzare un polyfill come MaxArt2501/object-observe o una libreria wrapper come polymer/observe-js.