Di hampir setiap versi Chrome, kami melihat sejumlah besar update dan peningkatan pada produk, performanya, serta kemampuan platform web.
Di Chrome 49 (Beta 2 Februari 2016. Tanggal stabil diperkirakan: Maret 2016) ada sejumlah perubahan pada Chrome
Penggunaan awalan "css" di getComputedStyle(e).cssX tidak digunakan lagi
Singkatnya: Penggunaan awalan "css" di
getComputedStyle(e)
telah dihentikan karena bukan bagian dari
spesifikasi formal.
getComputedStyle adalah fungsi kecil yang hebat. Metode ini akan menampilkan semua nilai CSS gaya elemen DOM sebagaimana telah dihitung oleh mesin rendering. Jadi, misalnya, Anda dapat menjalankan getComputedStyle(_someElement_).height dan mungkin akan menampilkan 224,1 px karena itulah tinggi elemen saat ini ditampilkan.
API ini tampaknya cukup berguna. Jadi, apa yang kita ubah?
Sebelum mesin rendering Chrome berubah menjadi Blink, Chrome didukung oleh WebKit dan memungkinkan Anda menambahkan awalan "css" di awal properti. Misalnya, getComputedStyle(e).cssHeight, bukan getComputedStyle(e).height.
Keduanya akan menampilkan data yang sama karena dipetakan ke nilai pokok yang sama,
tetapi penggunaan awalan "css" ini tidak standar, sudah tidak digunakan, dan telah dihapus.
Catatan - cssFloat adalah properti standar dan tidak terpengaruh oleh penghentian ini.
Jika Anda mengakses properti dengan cara ini di Chrome 49, properti akan menampilkan undefined dan Anda harus memperbaiki kode.
Penggunaan initTouchEvent tidak digunakan lagi
TL;DR:
initTouchEvent
tidak digunakan lagi dan digantikan dengan
TouchEvent
constructor untuk meningkatkan
kepatuhan terhadap spesifikasi dan akan dihapus sepenuhnya di Chrome 54.
Maksud untuk Menghapus Pelacak Chromestatus Masalah CRBug
Sejak lama Anda dapat membuat peristiwa sentuhan sintetis di Chrome menggunakan API initTouchEvent, yang sering digunakan untuk menyimulasikan Peristiwa Sentuhan baik untuk menguji atau mengotomatiskan beberapa UI di situs Anda. Di Chrome 49, kami telah menghentikan penggunaan API ini dan akan menampilkan peringatan berikut dengan maksud untuk menghapusnya sepenuhnya di Chrome 53.
Ada sejumlah alasan mengapa perubahan ini baik.
Fitur ini juga tidak ada dalam spesifikasi Touch Events. Penerapan initTouchEvent di Chrome sama sekali tidak kompatibel dengan initTouchEvent API Safari dan berbeda dengan Firefox di Android. Terakhir, konstruktor TouchEvent jauh lebih mudah digunakan.
Diputuskan bahwa kami akan berupaya mengikuti spesifikasi, bukan mempertahankan API
yang tidak sesuai spesifikasi maupun kompatibel dengan satu-satunya implementasi lainnya.
Oleh karena itu, kami pertama-tama menghentikan penggunaan, lalu menghapus fungsi initTouchEvent
dan mewajibkan developer menggunakan konstruktor TouchEvent.
Ada penggunaan API ini di Web, tetapi kami tahu bahwa API ini digunakan oleh sejumlah kecil situs, jadi kami tidak menghapusnya secepat biasanya. Kami yakin bahwa beberapa penggunaan rusak karena situs tidak menangani tanda tangan versi Chrome.
Karena penerapan iOS dan Android/Chrome API initTouchEvent sangat berbeda, Anda sering kali memiliki beberapa kode seperti (sering lupa 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);
Pertama, hal ini buruk karena mencari "Android" di Agen Pengguna dan Chrome di Android akan cocok dan mengalami penghentian penggunaan ini. Namun, API ini belum dapat dihapus karena akan ada browser lain berbasis WebKit dan Blink yang lebih lama di Android untuk sementara waktu yang masih memerlukan dukungan API lama.
Untuk menangani TouchEvents dengan benar di web, Anda harus mengubah kode untuk mendukung Firefox, IE Edge, dan Chrome dengan memeriksa keberadaan TouchEvent pada objek window dan jika memiliki "panjang" positif (menunjukkan bahwa itu adalah konstruktor yang mengambil argumen), Anda harus menggunakannya.
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);
Penangan error dan keberhasilan diperlukan dalam metode RTCPeerConnection
TL;DR: Metode WebRTC
RTCPeerConnection createOffer()
dan createAnswer()
kini memerlukan handler error serta handler keberhasilan. Sebelumnya, metode ini dapat dipanggil hanya dengan handler keberhasilan. Penggunaan tersebut tidak digunakan lagi.
Di Chrome 49, kami juga telah menambahkan peringatan jika Anda memanggil
setLocalDescription()
atau setRemoteDescription()
tanpa memberikan pengendali error. Kami berencana menjadikan argumen
error handler wajib untuk metode ini di Chrome 50.
Hal ini merupakan bagian dari upaya untuk memperkenalkan promise pada metode ini, seperti yang diwajibkan oleh spesifikasi WebRTC.
Berikut contoh dari demo RTCPeerConnection WebRTC (main.js, baris 126):
function onCreateOfferSuccess(desc) {
pc1.setLocalDescription(desc, function() {
onSetLocalSuccess(pc1);
}, onSetSessionDescriptionError);
pc2.setRemoteDescription(desc, function() {
onSetRemoteSuccess(pc2);
}, onSetSessionDescriptionError);
pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
}
Perhatikan bahwa setLocalDescription() dan setRemoteDescription() selalu memiliki parameter pengendali error, jadi cukup menentukan parameter tersebut adalah perubahan yang aman.
Secara umum, untuk aplikasi WebRTC produksi, sebaiknya gunakan adapter.js, shim yang dikelola oleh project WebRTC, untuk mengisolasi aplikasi dari perubahan spesifikasi dan perbedaan awalan.
Document.defaultCharset tidak digunakan lagi
TL;DR: Document.defaultCharset telah dihentikan untuk meningkatkan kepatuhan terhadap spesifikasi.
Maksud untuk Menghapus Pelacak Chromestatus Masalah CRBug
Document.defaultCharset adalah properti hanya baca yang menampilkan encoding karakter default sistem pengguna berdasarkan setelan regionalnya. Nilai ini tidak ditemukan berguna untuk dipertahankan karena cara browser menggunakan informasi encoding karakter dalam Respons HTTP atau dalam tag meta yang disematkan di halaman.
Dengan menggunakan document.characterSet, Anda akan mendapatkan nilai pertama yang ditentukan di header HTTP. Jika tidak ada, Anda akan mendapatkan nilai yang ditentukan dalam
atribut charset elemen <meta> (misalnya, <meta charset="utf-8">).
Terakhir, jika tidak ada yang tersedia, document.characterSet akan menjadi
setelan sistem pengguna.
Gecko belum mendukung properti ini dan tidak ditentukan dengan jelas, sehingga properti ini akan dihentikan penggunaannya dari Blink di Chrome 49 (Beta pada Januari 2016). Peringatan berikut akan muncul di konsol Anda hingga properti dihapus di Chrome 50:
Diskusi lebih lanjut tentang alasan tidak menentukan hal ini dapat dibaca di GitHub https://github.com/whatwg/dom/issues/58
getStorageUpdates() dihapus
TL;DR: Navigator.getStorageUpdates() telah dihapus karena tidak lagi ada dalam
spesifikasi Navigator.
Maksud untuk Menghapus Pelacak Chromestatus Masalah CRBug
Jika hal ini memengaruhi siapa pun, saya akan memakan topi saya. getStorageUpdates() hampir tidak pernah
(jika pernah) digunakan di web.
Untuk mengutip spesifikasi HTML5 (versi sangat lama):
Keren, kan? Spesifikasi ini bahkan menggunakan kata "dari mana" (yang secara kebetulan merupakan satu-satunya contoh kata "dari mana" dalam spesifikasi). Di tingkat spesifikasi, ada StorageMutex yang mengontrol akses ke penyimpanan pemblokiran seperti localStorage dan cookie, dan API ini akan membantu membebaskan mutex tersebut sehingga skrip lain tidak akan diblokir oleh StorageMutex ini. Namun, fitur ini tidak pernah diterapkan, tidak didukung di IE atau Gecko, dan penerapan WebKit (dan dengan demikian Blink) telah menjadi no-op.
Fitur ini telah dihapus dari spesifikasi sejak lama dan telah dihapus sepenuhnya dari Blink (sejak lama fitur ini tidak beroperasi dan tidak melakukan apa pun meskipun dipanggil).
Jika Anda memiliki kode yang memanggil navigator.getStorageUpdates(), Anda harus memeriksa keberadaan fungsi tersebut sebelum memanggilnya.
Object.observe() tidak digunakan lagi
Singkatnya: Object.observe() tidak digunakan lagi karena tidak lagi dalam jalur standardisasi
dan akan dihapus dalam rilis mendatang.
Maksud untuk Menghapus Pelacak Chromestatus Masalah CRBug
Pada November 2015, diumumkan bahwa Object.Observe ditarik dari TC39. Fitur ini telah dihentikan sejak Chrome 49 dan Anda akan melihat peringatan berikut di konsol jika Anda mencoba menggunakannya:
Banyak developer menyukai API ini dan jika Anda telah bereksperimen dengannya dan sekarang mencari jalur transisi, pertimbangkan untuk menggunakan polyfill seperti MaxArt2501/object-observe atau library wrapper seperti polymer/observe-js.