Chrome のほぼすべてのバージョンで、プロダクト、パフォーマンス、ウェブ プラットフォームの機能に対して、多数の更新と改善が行われています。
Chrome 49（ベータ版は 2016 年 2 月 2 日。安定した予定日: 2016 年 3 月） Chrome にいくつかの変更が加えられています
getComputedStyle(e).cssX で接頭辞「css」の使用が非推奨に
要約: getComputedStyle(e) での接頭辞「css」の使用は、正式なspecには含まれていません。
getComputedStyle は便利な関数です。この関数は、レンダリング エンジンによって計算された DOM 要素のスタイルのすべての CSS 値を返します。たとえば、getComputedStyle(_someElement_).height を実行すると、224.1px が返される場合があります。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 Tracker CRBug の問題
Chrome では以前から、initTouchEvent API を使用して合成タッチイベントを作成できていました。これらは、サイトでの一部の UI のテストや自動化のために、タッチイベントをシミュレートするために頻繁に使用されています。この API は Chrome 49 でサポートが終了しました。Chrome 53 で完全に削除するため、次の警告が表示されます。
この変更が適切な理由はいくつかあります。また、タッチイベントの仕様にも含まれていません。Chrome で initTouchEvent を実装することは、Safari の initTouchEvent API とまったく互換性がなく、Android の Firefox とは異なります。最後は TouchEvent コンストラクタの方が使いやすいという特長です。
Google は、仕様も他の実装とも互換性もない API を維持するのではなく、仕様に従うことを目指すことにしました。そのため、まず initTouchEvent 関数を非推奨とし、デベロッパーに TouchEvent コンストラクタの使用を義務付けます。
この API はウェブでも使用されていますが、使用サイトの数は比較的少ないため、通常より迅速に削除することはできません。Google では、サイトが 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);
まず、ユーザー エージェントで「Android」を検索すると、Android の Chrome はそれと一致し、サポート終了となるため、これは好ましくありません。ただし、Android には他の WebKit ベースや古い Blink ベースのブラウザが当面存在するため、古い API をサポートする必要があることに変わりはありません。
ウェブで 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 プロジェクトで管理されている shim である adapter.js を使用して、アプリを仕様の変更や接頭辞の違いから分離することをおすすめします。
Document.defaultCharset の非推奨
要約: 仕様の遵守を改善するため、Document.defaultCharset のサポートが終了しました。
削除の目的 Chromestatus Tracker CRBug の問題
Document.defaultCharset は読み取り専用のプロパティで、ユーザーのリージョン設定に基づいて、ユーザーのシステムのデフォルトの文字エンコードを返します。ブラウザでは、HTTP レスポンスやページに埋め込まれたメタタグで文字エンコード情報が使用されるため、この値を維持してもあまり意味がありません。
document.characterSet を使用すると、HTTP ヘッダーで指定された最初の値を取得します。この属性が存在しない場合は、<meta> 要素の charset 属性で指定された値（例: <meta charset="utf-8">）が返されます。最終的に、値がいずれも利用できない場合は、document.characterSet がユーザーのシステム設定になります。
Gecko はこのプロパティをサポートしていないため、明確に仕様されていません。そのため、このプロパティは Chrome 49 の Blink で非推奨となります（2016 年 1 月よりベータ版）。Chrome 50 でプロパティが削除されるまで、コンソールに次の警告が表示されます。
この仕様を指定しない理由に関する詳しい説明は、GitHub で入手できます。https://github.com/whatwg/dom/issues/58
getStorageUpdates() を削除しました
要約: Navigator.getStorageUpdates() は Navigator の仕様に含まれなくなったため、削除されました。
削除の目的 Chromestatus Tracker CRBug の問題
もしこれが人に影響を与えたら、私の帽子を食べるつもりです。getStorageUpdates() がウェブで使用されることは、ほとんどありません。
（非常に古いバージョンの）HTML5 仕様を引用するには:
これはとても便利です。この仕様では、「whence」という単語も使用しています（この仕様では、Whence は唯一の事例です）。仕様レベルでは、ブロック ストレージ（localStorage や Cookie など）へのアクセスを制御する StorageMutex がありました。この API はミューテックスを解放し、他のスクリプトがこの StorageMutex によってブロックされないようにします。しかし、これは一度も実装されておらず、IE や Gecko ではサポートされておらず、WebKit（したがって Blink）の実装では機能していません。
しばらく前から仕様から削除され、Blink から完全に削除されました（長い間は何も実行されず、呼び出されても何も起こりませんでした）。
万が一、navigator.getStorageUpdates() を呼び出したコードがある場合は、この関数を呼び出す前にその関数の有無を確認する必要があります。
Object.observe() のサポート終了
要約: Object.observe() は標準化トラックから除外され、今後のリリースで削除されるため、非推奨になりました。
削除の目的 Chromestatus Tracker CRBug の問題
2015 年 11 月に、Object.Observe が TC39 から除外されることが発表されました。この機能は Chrome 49 でサポートが終了しているため、使用しようとするとコンソールに次の警告が表示されます。
多くのデベロッパーがこの API を高く評価しています。すでにこの API を試していて、移行パスを探している場合は、MaxArt2501/object-observe などのポリフィルや、polymer/observe-js などのラッパー ライブラリの使用を検討してください。