在幾乎每個 Chrome 版本中，我們都會看到產品、效能和網路平台功能有大量更新和改良。
在 Chrome 49 版 (2016 年 2 月 2 日推出 Beta 版) 中，預計於 2016 年 3 月發布穩定版)，Chrome 將進行多項變更，
getComputedStyle(e).cssX 中使用「css」前置字串已淘汰
TL;DR：getComputedStyle(e) 中的「css」前置字元已遭淘汰，因為它並非正式規格的一部分。
getComputedStyle 是一個很棒的小函式。這個方法會傳回 DOM 元素樣式的全部 CSS 值，這些值是由算繪引擎計算而得。舉例來說，您可以執行 getComputedStyle(_someElement_).height，系統可能會傳回 224.1 像素，因為這是元素目前顯示的高度。
這項 API 似乎相當實用。那麼，我們將進行哪些變更？
在 Chrome 的算繪引擎改用 Blink 之前，Chrome 是由 WebKit 驅動，因此您可以在屬性開頭加上「css」前置字元。例如：顯示 getComputedStyle(e).cssHeight，而不是 getComputedStyle(e).height。
兩者都會對應至相同的基礎值，因此傳回的資料相同，但「css」前置字元的用法不符合標準，因此已遭淘汰並移除。
注意：cssFloat 是標準屬性，不受本次淘汰作業影響。
如果您在 Chrome 49 中以這種方式存取屬性，系統會傳回 undefined，您必須修正程式碼。
initTouchEvent 已淘汰
TL;DR：
initTouchEvent
已淘汰，並改用
TouchEvent
constructor，以提升
規格相容性，並將在 Chrome 54 中完全移除。
移除意圖 Chromestatus 追蹤工具 CRBug 問題
長期以來，您都能在 Chrome 中使用 initTouchEvent API 建立合成觸控事件，這些事件通常用於模擬觸控事件，以測試或自動化網站中的某些 UI。我們已在 Chrome 49 中淘汰這項 API，並會顯示下列警告，預計在 Chrome 53 中完全移除這項 API。
這項異動有許多優點。
此外，觸控事件規格中也沒有這項屬性。Chrome 實作的 initTouchEvent 完全不相容於 Safari 的 initTouchEvent API，且與 Android 版 Firefox 的實作方式不同。最後，TouchEvent 建構函式更容易使用。
我們決定遵循規格，而不是維護既不符合規格，也不與唯一其他實作項目相容的 API。因此，我們將先淘汰 initTouchEvent 函式，然後移除該函式，並要求開發人員使用 TouchEvent 建構函式。
網路上有使用這個 API 的情況，但我們知道使用這個 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 會比對並觸發這項淘汰作業，因此不建議使用。不過，由於 Android 上仍有其他 WebKit 和舊版 Blink 瀏覽器，您仍需支援舊版 API，因此目前無法移除。
如要在網路上正確處理 TouchEvents，請檢查 window 物件上是否存在 TouchEvent，並確認其「長度」是否為正數 (表示這是會採用引數的建構函式)，然後使用該函式，藉此支援 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 中，將這些方法設為必須提供錯誤處理常式引數。
這是為在這些方法中導入 Promise 鋪路，因為 WebRTC 規格要求這麼做。
以下是 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 應用程式，我們建議使用 adapter.js (由 WebRTC 專案維護的墊片)，避免應用程式受到規格變更和前置字元差異的影響。
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 月的 Beta 版) 將淘汰 Blink 中的這項屬性。在 Chrome 50 中移除該屬性之前，主控台會顯示下列警告：
如要進一步瞭解不指定此項目的原因，請參閱 GitHub 上的討論： https://github.com/whatwg/dom/issues/58
已移除 getStorageUpdates()
TL;DR：Navigator.getStorageUpdates() 已移除，因為它不再屬於 Navigator 規格。
移除意圖 Chromestatus 追蹤工具 CRBug 問題
如果這項異動會影響任何人，我會吃掉自己的帽子。getStorageUpdates() 幾乎從未在網路上使用過。
引用 (非常舊版本) 的 HTML5 規格：
聽起來很酷吧？規格甚至使用「whence」一詞 (巧合的是，這是規格中唯一出現的 whence 執行個體)。在規格層級，有一個 StorageMutex 可控管對封鎖儲存空間 (例如 localStorage 和 Cookie) 的存取權，這個 API 可協助釋放該互斥鎖，讓其他指令碼不會遭到這個 StorageMutex 封鎖。但這項功能從未實作，IE 或 Gecko 也不支援，而且 WebKit (因此 Blink) 的實作方式是無作業。
這項功能已從規格中移除一段時間，且已從 Blink 完全移除 (即使呼叫，這項功能也已長時間處於無運算狀態，不會執行任何動作)。
萬一您有呼叫 navigator.getStorageUpdates() 的程式碼，則必須先檢查函式是否存在，再呼叫函式。
Object.observe() 已淘汰
摘要：Object.observe() 已淘汰，因為不再屬於標準化軌跡，且將在日後推出的版本中移除。
移除意圖 Chromestatus 追蹤工具 CRBug 問題
2015 年 11 月，我們宣布要從 TC39 撤回 Object.Observe。這項功能已在 Chrome 49 中淘汰，如果您嘗試使用，控制台會顯示下列警告：
許多開發人員都很喜歡這個 API，如果您曾試用過這個 API，現在想尋找轉移路徑，建議使用 MaxArt2501/object-observe 等 Polyfill，或是 polymer/observe-js 等封裝函式庫。