ほぼすべてのバージョンの Chrome で、プロダクト、パフォーマンス、ウェブ プラットフォームの機能に多数の更新と改善が加えられています。
Chrome 49（2016 年 2 月 2 日にベータ版をリリース）では、（2016 年 3 月の安定版リリース予定）Chrome には多くの変更が加えられています。
getComputedStyle(e).cssX での「css」接頭辞の使用は非推奨になりました
要約: getComputedStyle(e) での「css」接頭辞の使用は、正式な仕様の一部ではなかったため、非推奨になりました。
getComputedStyle は優れた小さな関数です。レンダリング エンジンによって計算された DOM 要素のスタイルのすべての CSS 値を返します。たとえば、getComputedStyle(_someElement_).height を実行すると、要素の現在の表示高さである 224.1px が返されることがあります。
かなり便利な API のようです。変更点
Chrome のレンダリング エンジンが Blink に変更される前は、WebKit が使用されており、プロパティの先頭に「css」という接頭辞を付けることができました。たとえば、getComputedStyle(e).height ではなく getComputedStyle(e).cssHeight です。どちらも同じ基盤となる値にマッピングされるため、同じデータを返しますが、「css」接頭辞の使用は標準ではなく、非推奨となり削除されました。
注 - cssFloat は標準プロパティであり、今回の非推奨化の影響を受けません。
Chrome 49 でこの方法でプロパティにアクセスすると、undefined が返されるため、コードを修正する必要があります。
initTouchEvent の使用は非推奨
要約:
initTouchEvent
は、仕様への準拠を改善するために TouchEvent
constructor に置き換えられ、Chrome 54 で完全に削除されます。
削除の意向 Chromestatus トラッカー CRBug の問題
Chrome では、initTouchEvent API を使用して合成タッチイベントを長らく作成できます。これは、テストやサイトの UI の自動化のためにタッチイベントをシミュレートする際によく使用されます。Chrome 49 ではこの API は非推奨となり、Chrome 53 で完全に削除する予定で、次の警告が表示されます。
この変更が望ましい理由はいくつかあります。また、Touch Events 仕様にも含まれていません。Chrome の initTouchEvent の実装は、Safari の initTouchEvent API とまったく互換性がなく、Android 版 Firefox とも異なっていました。最後に、TouchEvent コンストラクタははるかに使いやすくなっています。
仕様に準拠することを目標とし、仕様に準拠しておらず、他の実装とも互換性がない API を維持することはしないことが決定されました。そのため、まず initTouchEvent 関数を非推奨にしてから削除し、デベロッパーが TouchEvent コンストラクタを使用することを義務付けます。
この API はウェブ上で使用されていますが、比較的少数のサイトで使用されていることがわかっているため、通常ほど迅速には削除していません。サイトが Chrome の署名バージョンを処理していないため、一部の利用が機能していないと考えています。
initTouchEvent API の iOS と Android/Chrome の実装は大きく異なっていたため、次のようなコードがよく見られました（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);
まず、これは User-Agent で「Android」を検索するため、Android 版 Chrome が一致してこの非推奨に該当します。ただし、古い API をサポートする必要がある WebKit ベースや古い Blink ベースのブラウザが Android にしばらく残るため、まだ削除できません。
ウェブで TouchEvents を正しく処理するには、window オブジェクトで TouchEvent の存在を確認し、正の「length」がある場合（引数を取るコンストラクタであることを示す）はそれを使用することで、Firefox、IE Edge、Chrome をサポートするようにコードを変更する必要があります。
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);
RTCPeerConnection メソッドでエラー ハンドラと成功ハンドラが必要
要約: WebRTC の RTCPeerConnection メソッド createOffer() と createAnswer() で、成功ハンドラだけでなくエラー ハンドラも必要になりました。以前は、成功ハンドラのみでこれらのメソッドを呼び出すことができました。この使用方法は非推奨です。
Chrome 49 では、エラー ハンドラを指定せずに setLocalDescription() または setRemoteDescription() を呼び出した場合に警告を追加しました。Chrome 50 では、これらのメソッドのエラー ハンドラ引数が必須になる予定です。
これは、WebRTC 仕様で求められているように、これらのメソッドに Promise を導入するための準備の一環です。
WebRTC の RTCPeerConnection デモ（main.js、126 行目）の例を次に示します。
function onCreateOfferSuccess(desc) {
pc1.setLocalDescription(desc, function() {
onSetLocalSuccess(pc1);
}, onSetSessionDescriptionError);
pc2.setRemoteDescription(desc, function() {
onSetRemoteSuccess(pc2);
}, onSetSessionDescriptionError);
pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
}
setLocalDescription() と setRemoteDescription() の両方には常にエラー ハンドラ パラメータがあったため、単にそのパラメータを指定するだけで安全に変更できます。
一般に、本番環境の WebRTC アプリケーションでは、WebRTC プロジェクトによって維持されているシムである adapter.js を使用して、仕様の変更や接頭辞の違いからアプリを分離することをおすすめします。
Document.defaultCharset は非推奨
要約: 仕様の準拠を改善するため、Document.defaultCharset は非推奨になりました。
削除の意向 Chromestatus トラッカー CRBug の問題
Document.defaultCharset は、ユーザーのシステムにおけるデフォルトの文字エンコードを、地域設定に基づいて返す読み取り専用のプロパティです。ブラウザが HTTP レスポンスまたはページに埋め込まれたメタタグの文字エンコード情報を使用する方法のため、この値を維持することは有用ではないことがわかっています。
document.characterSet を使用すると、HTTP ヘッダーで指定された最初の値を取得できます。この値がない場合は、<meta> 要素の charset 属性で指定された値（<meta charset="utf-8"> など）が取得されます。最後に、これらの値がすべて利用できない場合は、document.characterSet がユーザーのシステム設定になります。
Gecko はこのプロパティをサポートしておらず、明確に仕様化されていないため、このプロパティは Chrome 49（2016 年 1 月にベータ版）の Blink から非推奨になります。Chrome 50 でプロパティが削除されるまで、コンソールに次の警告が表示されます。
この仕様を定めない理由についての議論は、github の https://github.com/whatwg/dom/issues/58 で読むことができます。
getStorageUpdates() を削除
TL;DR: Navigator.getStorageUpdates() は Navigator 仕様から削除されたため、削除されました。
削除の意向 Chromestatus トラッカー CRBug の問題
この変更が誰かに影響を与えるようなら、私は帽子を食べます。getStorageUpdates() はウェブ上でほとんど使用されていません。
HTML5 仕様（非常に古いバージョン）を引用すると、次のようになります。
これはとても便利です。仕様では「whence」という単語も使用されています（これは仕様で whence が使用されている唯一の例です）。仕様レベルでは、localStorage や Cookie などのブロック ストレージへのアクセスを制御する StorageMutex がありました。この API は、他のスクリプトがこの StorageMutex によってブロックされないように、そのミューテックスを解放するのに役立ちます。しかし、この機能は実装されたことがなく、IE や Gecko ではサポートされていません。WebKit（つまり Blink）の実装は no-op でした。
かなり前から仕様から削除されており、Blink から完全に削除されています（長い間、呼び出されても何も行わない no-op でした）。
navigator.getStorageUpdates() を呼び出すコードがある場合は、関数が存在するかどうかを確認してから呼び出す必要があります。
Object.observe() は非推奨
要約: Object.observe() は、標準化の対象ではなくなったため非推奨となり、今後のリリースで削除される予定です。
削除の意向 Chromestatus トラッカー CRBug の問題
2015 年 11 月に、Object.Observe が TC39 から撤退することが発表されました。Chrome 49 で非推奨となり、使用しようとするとコンソールに次の警告が表示されます。
多くのデベロッパーがこの API を気に入っています。この API を試していて、移行パスを探している場合は、MaxArt2501/object-observe などのポリフィルや、polymer/observe-js などのラッパー ライブラリの使用を検討してください。