在几乎每个版本的 Chrome 中，我们都会对产品、其性能以及 Web 平台的功能进行大量更新和改进。
在 Chrome 49（2016 年 2 月 2 日的 Beta 版）中，估计稳定版发布日期：2016 年 3 月）对 Chrome 进行了一些更改
getComputedStyle(e).cssX 中使用“css”前缀已被弃用
总结：自 getComputedStyle(e) 不再是正式 规范的一部分以来，已弃用其中的“css”前缀。
getComputedStyle 是一个很棒的小函数。它将返回 DOM 元素样式的全部 CSS 值，这些值已由渲染引擎计算得出。因此，举例来说，您可以运行 getComputedStyle(_someElement_).height，它可能会返回 224.1 像素，因为这是元素当前显示的高度。
这似乎是一个非常方便的 API。那么，我们进行了哪些更改？
在 Chrome 的渲染引擎更改为 Blink 之前，它由 WebKit 提供支持，这让您可以在属性的开头添加“css”前缀。例如，getComputedStyle(e).cssHeight 而不是 getComputedStyle(e).height。
两者都会返回相同的数据，因为它们映射到相同的底层值，但使用“css”前缀的方式不标准，已被弃用并移除。
注意 - cssFloat 是一项标准属性，不受此次弃用的影响。
如果您在 Chrome 49 中以这种方式访问属性，系统将返回 undefined，您必须修复代码。
已弃用 initTouchEvent
总结：
initTouchEvent已被弃用，取而代之的是 TouchEvent
constructor，以提高规范合规性，并且将在 Chrome 54 中完全移除。
移除意向 Chromestatus 跟踪器 CRBug 问题
长期以来，您一直可以使用 initTouchEvent API 在 Chrome 中创建合成触控事件，这些事件经常用于模拟触控事件，以便测试或自动执行网站中的某些界面操作。在 Chrome 49 中，我们已弃用此 API，并会显示以下警告，目的是在 Chrome 53 中完全移除此 API。
这项变更之所以有益，原因有很多。
它也不在触控事件规范中。Chrome 实现的 initTouchEvent 与 Safari 的 initTouchEvent API 完全不兼容，并且与 Android 版 Firefox 的不同。最后，TouchEvent 构造函数更易于使用。
我们最终决定，将努力遵循规范，而不是维护一个既没有规范又与唯一其他实现不兼容的 API。因此，我们首先会废弃 initTouchEvent 函数，然后将其移除，并要求开发者使用 TouchEvent 构造函数。
Web 上有此 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。
为了在 Web 上正确处理 TouchEvents，您应该更改代码以支持 Firefox、IE Edge 和 Chrome，方法是检查 window 对象上是否存在 TouchEvent，如果存在且“length”为正值（表示它是一个接受实参的构造函数），您应该使用该构造函数。
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 项目维护的 shim），以使应用不受规范变更和前缀差异的影响。
Document.defaultCharset 已弃用
要点：为了提高规范合规性，Document.defaultCharset 已被弃用。
移除意向 Chromestatus 跟踪器 CRBug 问题
Document.defaultCharset 是一种只读属性，用于根据用户的区域设置返回用户系统的默认字符编码。由于浏览器使用 HTTP 响应或网页中嵌入的元标记中的字符编码信息的方式，因此维护此值并无用处。
使用 document.characterSet 将获得 HTTP 标头中指定的第一个值。如果不存在该属性，您将获得 <meta> 元素的 charset 属性中指定的值（例如 <meta charset="utf-8">）。最后，如果上述属性均不可用，document.characterSet 将是用户的系统设置。
Gecko 尚未支持此属性，并且此属性的规范不明确，因此 Blink 将在 Chrome 49（2016 年 1 月的 Beta 版）中弃用此属性。在 Chrome 50 中移除该属性之前，您的控制台中会显示以下警告：
如需详细了解不指定此规范的原因，请访问 GitHub https://github.com/whatwg/dom/issues/58
移除了 getStorageUpdates()
总结：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，如果您一直在尝试使用它，现在正在寻找过渡方案，不妨考虑使用 MaxArt2501/object-observe 等 Polyfill 或 polymer/observe-js 等封装容器库。