Penghentian dan Penghapusan API di Chrome 49

Di hampir setiap versi Chrome, kami mendapatkan sejumlah update dan peningkatan yang signifikan pada produk, performanya, dan juga kemampuan platform web.

Di Chrome 49 (2 Februari 2016 Beta. Perkiraan tanggal stabil: Maret 2016) ada sejumlah perubahan pada Chrome

Penggunaan awalan "css" di getComputedStyle(e.cssX tidak digunakan lagi

TL;DR: Penggunaan awalan "css" di getComputedStyle(e) tidak digunakan lagi karena bukan bagian dari spec formal.

• Rencana Penghapusan
• Pelacak Chromestatus
• Masalah CRBug

getComputedStyle adalah fungsi kecil yang bagus. Tindakan ini akan menampilkan semua nilai CSS gaya elemen DOM seperti yang telah dihitung oleh mesin rendering. Jadi, misalnya, Anda dapat menjalankan getComputedStyle(_someElement_).height dan mungkin menampilkan 224,1 piksel karena itu adalah tinggi elemen seperti yang saat ini ditampilkan.

Tampaknya API ini cukup berguna. Jadi, apa yang kita ubah?

Sebelum mesin rendering Chrome berubah menjadi Blink, mesin ini didukung oleh WebKit dan yang memungkinkan Anda menambahkan awalan "css" ke awal properti. Misalnya, getComputedStyle(e).cssHeight, bukan getComputedStyle(e).height. Keduanya akan menampilkan data yang sama seperti yang dipetakan ke nilai dasar yang sama, tetapi penggunaan awalan "css" inilah yang tidak standar dan tidak digunakan lagi serta dihapus.

Catatan - cssFloat adalah properti standar dan tidak terpengaruh oleh penghentian ini.

Jika Anda mengakses properti dengan cara ini di Chrome 49, properti tersebut 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 spesifikasi dan akan dihapus sepenuhnya di Chrome 54.

Rencana Penghapusan Pelacak Status Chrome Masalah CRBug

Sejak lama Anda dapat membuat peristiwa sentuh sintetis di Chrome menggunakan initTouchEvent API, peristiwa ini sering digunakan untuk menyimulasikan Peristiwa Sentuh baik untuk pengujian maupun otomatisasi beberapa UI di situs Anda. Di Chrome 49, kami telah menghentikan API ini dan akan menampilkan peringatan berikut dengan tujuan untuk menghapusnya sepenuhnya di Chrome 53.

Ada sejumlah alasan mengapa perubahan ini bagus. Ini juga tidak ada dalam spesifikasi Peristiwa Sentuh. Implementasi Chrome initTouchEvent sama sekali tidak kompatibel dengan initTouchEvent API Safari dan berbeda dengan Firefox di Android. Dan terakhir, konstruktor TouchEvent jauh lebih mudah digunakan.

Diputuskan bahwa kami akan mengikuti spesifikasi ini, bukan mempertahankan API yang tidak ditentukan atau tidak kompatibel dengan satu-satunya implementasi lain. Oleh karena itu, pertama-tama kami menghentikan penggunaan lalu menghapus fungsi initTouchEvent dan mewajibkan developer menggunakan konstruktor TouchEvent.

API ini digunakan di Web, tetapi kami menyadari bahwa API ini digunakan oleh jumlah situs yang relatif rendah sehingga kami tidak menghapusnya secepat biasanya. Kami yakin bahwa beberapa penggunaan ini tidak berfungsi karena situs tidak menangani tanda tangan versi Chrome.

Karena implementasi iOS dan Android/Chrome dari initTouchEvent API sangat berbeda, Anda akan sering memiliki beberapa kode di sepanjang baris (sering melupakan 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, ini buruk karena mencari "Android" di Agen Pengguna dan Chrome di Android akan mencocokkan dan mencapai penghentian ini. API ini belum dapat dihapus karena akan ada browser berbasis WebKit dan Blink lama lainnya di Android untuk sementara waktu, dan Anda masih harus mendukung API lama.

Untuk menangani TouchEvents di web dengan benar, Anda harus mengubah kode untuk mendukung Firefox, IE Edge, dan Chrome dengan memeriksa keberadaan TouchEvent pada objek window dan apakah memiliki "panjang" positif (menunjukkan bahwa konstruktor yang memerlukan 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);

Pengendali error dan keberhasilan diperlukan dalam metode RTCPeerConnection

TL;DR: Metode RTCPeerConnection WebRTC createOffer() dan createAnswer() sekarang memerlukan pengendali error serta pengendali yang berhasil. Sebelumnya, metode ini dapat dipanggil hanya dengan pengendali yang berhasil. Penggunaan tersebut tidak digunakan lagi.

Di Chrome 49, kami juga telah menambahkan peringatan jika Anda memanggil setLocalDescription() atau setRemoteDescription() tanpa menyediakan pengendali error. Kami berharap agar argumen pengendali error wajib ada untuk metode ini di Chrome 50.

Ini merupakan bagian dari pembersihan cara untuk memperkenalkan promise pada metode ini, seperti yang diperlukan oleh spesifikasi WebRTC.

Berikut ini 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 melindungi aplikasi dari perubahan spesifikasi dan perbedaan awalan.

Document.defaultCharset tidak digunakan lagi

TL;DR: Document.defaultCharset tidak digunakan lagi untuk meningkatkan kepatuhan spesifikasi.

Rencana Penghapusan Pelacak Status Chrome Masalah CRBug

Document.defaultCharset adalah properti hanya baca yang menampilkan encoding karakter default dari sistem pengguna berdasarkan setelan regionalnya. Mempertahankan nilai ini tidaklah berguna karena cara browser menggunakan informasi encoding karakter dalam Respons HTTP atau dalam tag meta yang disematkan pada halaman.

Dengan menggunakan document.characterSet, Anda akan mendapatkan nilai pertama yang ditentukan pada header HTTP. Jika tidak ada, Anda akan mendapatkan nilai yang ditentukan dalam atribut charset dari elemen <meta> (misalnya, <meta charset="utf-8">). Terakhir, jika tidak ada satu pun opsi yang tersedia, document.characterSet akan menjadi setelan sistem pengguna.

Gecko belum mendukung properti ini dan properti ini tidak ditentukan dengan rapi sehingga properti ini tidak akan digunakan lagi dari Blink di Chrome 49 (Beta pada Januari 2016). Peringatan berikut akan muncul di konsol Anda hingga properti tersebut dihapus di Chrome 50:

Diskusi lebih lanjut tentang alasan untuk 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.

Rencana Penghapusan Pelacak Status Chrome Masalah CRBug

Jika ini berdampak terhadap siapa pun, saya akan memakan topi saya. getStorageUpdates() hampir tidak pernah (jika sama sekali) digunakan di web.

Mengutip spesifikasi HTML5 (versi yang sangat lama):

Keren, kan? Spesifikasi ini bahkan menggunakan kata "whence" (yang jika kemunculan merupakan satu-satunya instance dalam spesifikasi). Pada tingkat spesifikasi ada StorageMutex yang mengontrol akses untuk memblokir penyimpanan seperti localStorage dan cookie, dan API ini akan membantu membebaskan mutex tersebut sehingga skrip lain tidak akan diblokir oleh StorageMutex ini. Namun tidak pernah diimplementasikan, tidak didukung di IE atau Gecko, dan implementasi WebKit (dan juga Blink) tidak beroperasi.

Fitur ini telah cukup lama dihapus dari spesifikasi dan telah dihapus sepenuhnya dari Blink (untuk waktu yang lama tanpa pengoperasian dan tidak melakukan apa pun meskipun dipanggil).

Jika memiliki kode yang memanggil navigator.getStorageUpdates(), kemungkinan Anda harus memeriksa keberadaan fungsi tersebut sebelum memanggilnya.

Object.observe() tidak digunakan lagi

TL;DR: Object.observe() tidak digunakan lagi karena tidak lagi berada di jalur standardisasi dan akan dihapus dalam rilis mendatang.

Rencana Penghapusan Pelacak Status Chrome Masalah CRBug

Pada November 2015, diumumkan bahwa Object.Observe dibatalkan dari TC39. API ini tidak digunakan lagi dari Chrome 49 dan Anda akan melihat peringatan berikut di konsol jika mencoba menggunakannya:

Banyak developer yang menyukai API ini dan jika Anda bereksperimen dengan API ini dan sekarang sedang mencari jalur transisi, pertimbangkan untuk menggunakan polyfill seperti MaxArt2501/object-observe atau library wrapper seperti polymer/observe-js.