Trong hầu hết mọi phiên bản Chrome, chúng tôi đều thấy một số lượng đáng kể các bản cập nhật và cải tiến cho sản phẩm, hiệu suất của sản phẩm cũng như các chức năng của nền tảng web.
Trong Chrome 49 (Bản thử nghiệm ngày 2 tháng 2 năm 2016. Ngày phát hành phiên bản ổn định dự kiến: tháng 3 năm 2016) có một số thay đổi đối với Chrome
Việc sử dụng tiền tố "css" trong getComputedStyle(e).cssX không được dùng nữa
TL;DR: Việc sử dụng tiền tố "css" trong getComputedStyle(e) đã bị ngừng sử dụng vì tiền tố này không thuộc quy cách chính thức.
getComputedStyle là một hàm nhỏ nhưng hữu ích. Thao tác này sẽ trả về tất cả các giá trị CSS của kiểu phần tử DOM khi chúng được công cụ kết xuất tính toán. Ví dụ: bạn có thể chạy getComputedStyle(_someElement_).height và nó có thể trả về 224, 1px vì đó là chiều cao của phần tử khi phần tử đó hiện đang hiển thị.
Đây có vẻ là một API khá hữu ích. Vậy chúng tôi sẽ thay đổi điều gì?
Trước khi công cụ kết xuất của Chrome thay đổi thành Blink, công cụ này được hỗ trợ bởi WebKit và cho phép bạn thêm tiền tố "css" vào đầu một thuộc tính. Ví dụ: getComputedStyle(e).cssHeight thay vì getComputedStyle(e).height.
Cả hai đều sẽ trả về cùng một dữ liệu vì chúng được liên kết với cùng một giá trị cơ bản, nhưng chính việc sử dụng tiền tố "css" này là không chuẩn và đã bị ngừng sử dụng cũng như bị xoá.
Lưu ý: cssFloat là một thuộc tính tiêu chuẩn và không chịu ảnh hưởng của việc ngừng sử dụng này.
Nếu bạn truy cập vào một thuộc tính theo cách này trong Chrome 49, thì thuộc tính đó sẽ trả về undefined và bạn sẽ phải sửa mã.
Không nên dùng initTouchEvent
Tóm tắt:
initTouchEvent
đã ngừng hoạt động để thay thế bằng
TouchEvent
constructor nhằm cải thiện khả năng tuân thủ quy cách và sẽ bị loại bỏ hoàn toàn trong Chrome 54.
Ý định xoá Công cụ theo dõi trạng thái của Chrome Vấn đề về CRBug
Trong một thời gian dài, bạn có thể tạo các sự kiện chạm giả tạo trong Chrome bằng cách sử dụng API initTouchEvent. Các sự kiện này thường được dùng để mô phỏng Sự kiện chạm cho mục đích kiểm thử hoặc tự động hoá một số giao diện người dùng trên trang web của bạn. Trong Chrome 49, chúng tôi đã ngừng dùng API này và sẽ hiển thị cảnh báo sau đây với ý định xoá hoàn toàn API này trong Chrome 53.
Thay đổi này mang lại nhiều lợi ích.
API này cũng không có trong quy cách Sự kiện chạm. Việc triển khai initTouchEvent của Chrome hoàn toàn không tương thích với API initTouchEvent của Safari và khác với API initTouchEvent của Firefox trên Android. Và cuối cùng, hàm khởi tạo TouchEvent dễ sử dụng hơn nhiều.
Chúng tôi quyết định sẽ tuân theo quy cách thay vì duy trì một API không được quy định và không tương thích với việc triển khai duy nhất khác.
Do đó, trước tiên, chúng tôi sẽ ngừng hỗ trợ rồi xoá hàm initTouchEvent và yêu cầu nhà phát triển sử dụng hàm tạo TouchEvent.
Có một số trang web sử dụng API này, nhưng chúng tôi biết rằng chỉ có tương đối ít trang web sử dụng API này nên chúng tôi không xoá API này nhanh như bình thường. Chúng tôi cho rằng một số hoạt động sử dụng bị gián đoạn do các trang web không xử lý phiên bản chữ ký của Chrome.
Vì việc triển khai API initTouchEvent trên iOS và Android/Chrome khác nhau rất nhiều nên bạn thường có một số mã theo kiểu (thường quên 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);
Trước tiên, điều này là không nên vì nó tìm kiếm "Android" trong User-Agent và Chrome trên Android sẽ khớp và gặp phải trường hợp không dùng nữa này. Tuy nhiên, bạn chưa thể xoá API này vì sẽ có những trình duyệt khác dựa trên WebKit và Blink cũ trên Android mà bạn vẫn cần hỗ trợ API cũ.
Để xử lý chính xác TouchEvents trên web, bạn nên thay đổi mã để hỗ trợ Firefox, IE Edge và Chrome bằng cách kiểm tra sự tồn tại của TouchEvent trên đối tượng window và nếu đối tượng này có "độ dài" dương (cho biết đây là một hàm khởi tạo nhận một đối số), thì bạn nên sử dụng hàm khởi tạo đó.
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);
Cần có trình xử lý lỗi và thành công trong các phương thức RTCPeerConnection
Tóm tắt: Các phương thức WebRTC RTCPeerConnection createOffer() và createAnswer() hiện yêu cầu một trình xử lý lỗi cũng như một trình xử lý thành công. Trước đây, bạn có thể gọi các phương thức này chỉ bằng một trình xử lý thành công. Cách sử dụng đó không còn được dùng nữa.
Trong Chrome 49, chúng tôi cũng đã thêm một cảnh báo nếu bạn gọi setLocalDescription() hoặc setRemoteDescription() mà không cung cấp trình xử lý lỗi. Chúng tôi dự kiến sẽ bắt buộc đối số trình xử lý lỗi cho các phương thức này trong Chrome 50.
Đây là một phần của việc dọn đường để giới thiệu các lời hứa về những phương thức này, theo yêu cầu của thông số kỹ thuật WebRTC.
Sau đây là một ví dụ trong bản demo RTCPeerConnection của WebRTC (main.js, dòng 126):
function onCreateOfferSuccess(desc) {
pc1.setLocalDescription(desc, function() {
onSetLocalSuccess(pc1);
}, onSetSessionDescriptionError);
pc2.setRemoteDescription(desc, function() {
onSetRemoteSuccess(pc2);
}, onSetSessionDescriptionError);
pc2.createAnswer(onCreateAnswerSuccess, onCreateSessionDescriptionError);
}
Xin lưu ý rằng cả setLocalDescription() và setRemoteDescription() đều luôn có một tham số trình xử lý lỗi, vì vậy, việc chỉ định tham số đó là một thay đổi an toàn.
Nói chung, đối với các ứng dụng WebRTC sản xuất, bạn nên sử dụng adapter.js, một shim do dự án WebRTC duy trì, để cách ly các ứng dụng khỏi những thay đổi về thông số kỹ thuật và sự khác biệt về tiền tố.
Document.defaultCharset không được dùng nữa
Tóm tắt: Document.defaultCharset đã ngừng hoạt động để cải thiện việc tuân thủ quy cách.
Ý định xoá Công cụ theo dõi trạng thái của Chrome Vấn đề về CRBug
Document.defaultCharset là một thuộc tính chỉ đọc, trả về chế độ mã hoá ký tự mặc định của hệ thống người dùng dựa trên chế độ cài đặt khu vực của họ. Việc duy trì giá trị này không mang lại lợi ích gì do cách trình duyệt sử dụng thông tin mã hoá ký tự trong Phản hồi HTTP hoặc trong thẻ meta được nhúng trong trang.
Bằng cách sử dụng document.characterSet, bạn sẽ nhận được giá trị đầu tiên được chỉ định trong tiêu đề HTTP. Nếu không có giá trị đó, bạn sẽ nhận được giá trị được chỉ định trong thuộc tính charset của phần tử <meta> (ví dụ: <meta charset="utf-8">). Cuối cùng, nếu không có giá trị nào trong số đó, document.characterSet sẽ là chế độ cài đặt hệ thống của người dùng.
Gecko không hỗ trợ thuộc tính này và thuộc tính này không được chỉ định rõ ràng, vì vậy, thuộc tính này sẽ không được dùng nữa trong Blink từ Chrome 49 (Beta vào tháng 1 năm 2016). Cảnh báo sau đây sẽ xuất hiện trong bảng điều khiển cho đến khi thuộc tính này bị xoá trong Chrome 50:
Bạn có thể đọc thêm về lý do không chỉ định rõ điều này trên github https://github.com/whatwg/dom/issues/58
Đã xoá getStorageUpdates()
Tóm tắt: Navigator.getStorageUpdates() đã bị xoá vì không còn nằm trong thông số Navigator nữa.
Ý định xoá Công cụ theo dõi trạng thái của Chrome Vấn đề về CRBug
Nếu điều này ảnh hưởng đến bất kỳ ai, tôi sẽ ăn mũ của mình. getStorageUpdates() hầu như chưa bao giờ (nếu có) được sử dụng trên web.
Trích dẫn (phiên bản rất cũ) của quy cách HTML5:
Nghe có vẻ khá hay phải không? Thông số này thậm chí còn dùng từ "whence" (tình cờ là từ whence chỉ xuất hiện một lần trong thông số này). Ở cấp độ thông số kỹ thuật, có một StorageMutex kiểm soát quyền truy cập vào bộ nhớ chặn, chẳng hạn như localStorage và cookie. API này sẽ giúp giải phóng mutex đó để các tập lệnh khác không bị StorageMutex này chặn. Tuy nhiên, tính năng này chưa bao giờ được triển khai, không được hỗ trợ trong IE hoặc Gecko và việc triển khai của WebKit (và do đó là Blink) không có tác dụng.
Đã được xoá khỏi các thông số kỹ thuật một thời gian khá dài và đã bị xoá hoàn toàn khỏi Blink (trong thời gian dài nhất, nó không hoạt động và không làm gì ngay cả khi được gọi).
Trong trường hợp hiếm gặp là bạn có mã gọi navigator.getStorageUpdates(), thì bạn sẽ phải kiểm tra sự hiện diện của hàm trước khi gọi hàm đó.
Object.observe() không được dùng nữa
Tóm tắt: Object.observe() không còn được dùng nữa vì không còn nằm trong lộ trình tiêu chuẩn hoá và sẽ bị xoá trong một bản phát hành sau này.
Ý định xoá Công cụ theo dõi trạng thái của Chrome Vấn đề về CRBug
Vào tháng 11 năm 2015, người ta thông báo rằng Object.Observe sẽ bị rút khỏi TC39. API này đã ngừng hoạt động từ Chrome 49 và bạn sẽ thấy cảnh báo sau trong bảng điều khiển nếu cố gắng sử dụng API này:
Nhiều nhà phát triển thích API này và nếu bạn đã thử nghiệm API này và hiện đang tìm cách chuyển đổi, hãy cân nhắc sử dụng một polyfill như MaxArt2501/object-observe hoặc một thư viện trình bao bọc như polymer/observe-js.