Chrome 49 中的 API 弃用和移除

在几乎每个版本的 Chrome 中,我们都看到了针对产品及其性能以及网络平台功能的大量更新和改进。

适用于 Chrome 49(Beta 版,2016 年 2 月 2 日。预计的稳定日期:2016 年 3 月)

已弃用在 getComputedStyle(e).cssX 中使用“css”前缀

TL;DR:在 getComputedStyle(e) 中使用“css”前缀已被弃用,因为它不是正式spec的一部分。

getComputedStyle 是一个很棒的小函数。它将返回 DOM 元素样式的所有 CSS 值,因为呈现引擎已计算出这些值。例如,您可以运行 getComputedStyle(_someElement_).height,它可能会返回 224.1px,因为这是元素当前显示的高度。

这似乎是一个非常方便的 API。那么,我们要更改什么呢?

在 Chrome 的呈现引擎改为 Blink 之前,它由 WebKit 提供支持,允许您在属性的开头添加“css”前缀。例如,使用 getComputedStyle(e).cssHeight,而不是 getComputedStyle(e).height。两者都将返回相同的数据,因为它们映射到相同的底层值,但正是这种“css”前缀用法是不标准的,已被废弃和移除。

注意 - cssFloat 是标准属性,不受此弃用的影响。

如果您在 Chrome 49 中以这种方式访问属性,它将返回 undefined,您必须修复代码。

废弃了 initTouchEvent

要点initTouchEvent 已弃用,取而代之的是 TouchEvent constructor,以更好地符合规范要求,并将在 Chrome 54 中彻底移除。

打算移除 Chromestatus Tracker CRBug 问题

很长时间以来,您都可以使用 initTouchEvent API 在 Chrome 中创建合成触摸事件,这些事件经常用于模拟触摸事件,以测试或自动执行网站中的某些界面。在 Chrome 49 中,我们已弃用此 API,并显示以下警告,以便在 Chrome 53 中将其彻底移除。

“TouchEvent.initTouchEvent”已被弃用,并将于 2016 年 9 月左右在 M53 中移除。请改用 TouchEvent 构造函数。
“TouchEvent.initTouchEvent”已被弃用,并将于 2016 年 9 月左右在 M53 中移除。请改用 TouchEvent 构造函数。如需了解详情,请参阅 https://www.chromestatus.com/features/5730982598541312

有很多原因表明这项更改是好的。 它也未包含在触摸事件规范中。initTouchEvent 的 Chrome 实现与 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);

首先,这样做很不好,因为系统会在用户代理中查找“Android”,Android 版 Chrome 会匹配并达到此弃用。目前还无法将其移除,但由于 Android 上会有其他 WebKit 和旧版基于 Blink 的浏览器,但在一段时间内,您仍然需要支持旧版 API。

如需在网页上正确处理 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 中这些方法的必需参数。

这是按照 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 应用,我们建议您使用 adapter.js(一个由 WebRTC 项目维护的 shim),使应用免受规范更改和前缀差异的影响。

废弃了 Document.defaultCharset

TL;DR:为了更好地符合规范要求,废弃了 Document.defaultCharset

打算移除 Chromestatus Tracker CRBug 问题

Document.defaultCharset 是一个只读属性,会根据其区域设置返回用户系统的默认字符编码。由于浏览器会在 HTTP 响应或网页中嵌入的元标记中使用字符编码信息,因此维护此值并无帮助。

通过使用 document.characterSet,您将获取 HTTP 标头中指定的第一个值。如果该属性不存在,您将获得在 <meta> 元素的 charset 属性中指定的值(例如 <meta charset="utf-8">)。最后,如果它们都不可用,document.characterSet 将会是用户的系统设置。

Gecko 不支持此属性,并且未明确指定此属性,因此将在 Chrome 49(2016 年 1 月推出 Beta 版)的 Blink 中弃用此属性。在 Chrome 50 中移除相应属性之前,您的控制台中会显示以下警告:

“Document.defaultCharset”已被弃用,并将于 2016 年 4 月左右在 M50 中移除。
“Document.defaultCharset”已被弃用,并将于 2016 年 4 月左右在 M50 中移除。如需了解详情,请参阅 https://www.chromestatus.com/features/6217124578066432

有关不明确说明原因的更多讨论,可在 GitHub https://github.com/whatwg/dom/issues/58 上阅读。

移除了 getStorageUpdates()

TL;DR:移除了 Navigator.getStorageUpdates(),因为它不再存在于导航器规范中。

打算移除 Chromestatus Tracker CRBug 问题

如果这会影响到任何人,我会吃我的帽子。getStorageUpdates() 几乎没有(如果根本没有)在网络上使用。

要引用 HTML5 规范(非常旧的版本)规范,请执行以下操作:

听起来很酷吧?该规范甚至使用了“whence”一词(实际上,它是规范中唯一的 whence)。在规范级别,有一个 StorageMutex 用于控制对阻止存储(例如 localStorage 和 Cookie)的访问,并且此 API 可帮助释放该互斥量,以便此 StorageMutex 不会阻止其他脚本。但它从未实现,在 IE 或 Gecko 中不受支持,而且 WebKit(以及 Blink)的实现一直是一种空操作。

它已被从规范中移除了很长时间,并已从 Blink 中彻底移除(在最长的时间里,它一直是空操作,即使被调用,它也毫无效果)。

在极少数情况下,如果您有调用 navigator.getStorageUpdates() 的代码,那么您必须在调用该函数之前检查其是否存在。

废弃了 Object.observe()

TL;DRObject.observe() 已废弃,因为它不再位于标准化轨道中,并将在未来的版本中移除。

打算移除 Chromestatus Tracker CRBug 问题

2015 年 11 月,我们宣布将撤回 TC39 的 Object.Observe。从 Chrome 49 开始,此版本已弃用。如果您尝试使用它,会在控制台中看到以下警告:

“Object.observe”已被弃用,并将于 2016 年 4 月左右在 M50 中移除。
“Object.observe”已被弃用,并将于 2016 年 4 月左右在 M50 中移除。如需了解详情,请参阅 https://www.chromestatus.com/features/6147094632988672

许多开发者都喜欢此 API,如果您已试用该 API,现在正在寻找过渡路径,请考虑使用 polyfill(例如 MaxArt2501/object-observe)或封装容器库(例如 polymer/observe-js)。