Trong hầu hết mọi phiên bản Chrome, chúng tôi đều thấy có nhiều bản cập nhật và cải tiến đáng kể về sản phẩm, hiệu suất cũng như các tính năng của nền tảng web.
Trong Chrome 49 (Beta ngày 2 tháng 2 năm 2016. Ngày ổ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òn được dùng nữa
Tóm tắt: Việc sử dụng tiền tố "css" trong getComputedStyle(e) đã ngừng hoạt động vì tiền tố này không có trong spec chính thức.
getComputedStyle là một hàm nhỏ tuyệt vời. Thuộc tính này sẽ trả về tất cả giá trị CSS theo kiểu của phần tử DOM như đã được công cụ kết xuất tính toán. Ví dụ: bạn có thể chạy getComputedStyle(_someElement_).height và có thể trả về kích thước 224, 1px vì đó là chiều cao của phần tử đang hiển thị.
Đây có vẻ là một API khá tiện dụng. Vậy chúng tôi sẽ thay đổi những gì?
Trước khi công cụ kết xuất của Chrome chuyển thành Blink, công cụ này được hỗ trợ bởi Tin tức và cho phép bạn thêm tiền tố "css" vào phần đầu của thuộc tính. Ví dụ: getComputedStyle(e).cssHeight thay vì getComputedStyle(e).height.
Cả hai sẽ trả về cùng một dữ liệu khi chúng được ánh xạ tới cùng các giá trị cơ bản, nhưng việc sử dụng tiền tố "css" không chuẩn và đã không được dùng nữa và bị xoá.
Lưu ý – cssFloat là một thuộc tính 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, thuộc tính đó sẽ trả về undefined và bạn
sẽ phải sửa mã của mình.
Ngừng sử dụng initTouchEvent
Tóm tắt:
Chúng tôi đã ngừng sử dụng initTouchEvent
và thay vào đó là
TouchEvent
constructor để cải thiện
việc tuân thủ thông số kỹ thuật và sẽ bị xoá hoàn toàn trong Chrome 54.
Ý định xoá Trình theo dõi trạng thái Chrome Vấn đề về CRBug
Đã từ lâu, bạn có thể tạo các sự kiện chạm tổng hợp 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 các Sự kiện chạm nhằm kiểm tra hoặc tự động hoá một số giao diện người dùng trong trang web của bạn. Trong Chrome 49, chúng tôi đã ngừng sử 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.
Có một số lý do khiến thay đổi này có lợi.
API này cũng không có trong thông số kỹ thuật về Sự kiện chạm. Việc triển khai initTouchEvent trên Chrome hoàn toàn không tương thích với API initTouchEvent của Safari và khác với Firefox trên Android. 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 chỉ định cũng như không tương thích với phương thức triển khai duy nhất khác.
Do đó, trước tiên, chúng tôi sẽ ngừng sử dụng và sau đó xoá hàm initTouchEvent, đồng thời yêu cầu nhà phát triển sử dụng hàm khởi tạo TouchEvent.
Mặc dù có người dùng sử dụng API này trên web, nhưng chúng tôi biết rằng có một số lượng trang web tương đối sử dụng API này. Vì vậy, chúng tôi sẽ không xoá API này nhanh như bình thường. Chúng tôi tin rằng một số hoạt động sử dụng bị lỗi 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 rất khác nhau, nên bạn thường sẽ có một số mã dọc theo các dòng (thường xuyên 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);
Thứ nhất, điều này không tốt vì tìm kiếm "Android" trong Tác nhân người dùng và Chrome trên Android sẽ khớp và ngừng sử dụng này. Tuy nhiên, chưa thể xoá nó vì trong một khoảng thời gian, sẽ có các trình duyệt ngoại số và trình duyệt dựa trên Blink cũ hơn trên Android mà bạn vẫn sẽ cần phải 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à xem đối tượng đó có "độ dài" dương hay không (cho biết đó là hàm khởi tạo cần đối số), bạn nên sử dụng đối tượng đó.
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 phương thức RTCPeerConnection
TL;DR: Phương thức WebRTC
RTCPeerConnection createOffer()
và createAnswer()
hiện cần có 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ể chỉ gọi các phương thức này bằng một trình xử lý thành công. Phương thức sử dụng đó không còn được dùng nữa.
Trong Chrome 49, chúng tôi cũng thêm 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 hy vọng bắt buộc phải đưa đối số trình xử lý lỗi vào các phương thức này trong Chrome 50.
Đây là một phần của việc mở đường cho việc đưa ra lời hứa về các phương thức này, theo yêu cầu của thông số kỹ thuật WebRTC.
Dưới đây là ví dụ từ bản minh hoạ 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ó tham số trình xử lý lỗi, vì vậy, bạn chỉ cần chỉ định tham số đó là một thay đổi an toàn.
Nhìn chung, đối với các ứng dụng WebRTC phát hành chính thức, bạn nên dùng
adapter.js, một miếng đệm, do dự án
WebRTC duy trì, để giúp tách biệt ứng dụng khỏi các thay đổi về thông số kỹ thuật và sự khác biệt về tiền tố.
Ngừng sử dụng Document.defaultCharset
Tóm tắt: Chúng tôi đã ngừng sử dụng Document.defaultCharset để cải thiện việc tuân thủ thông số kỹ thuật.
Ý định xoá Trình theo dõi trạng thái Chrome Vấn đề về CRBug
Document.defaultCharset là một thuộc tính chỉ có thể đọ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 theo khu vực của họ. Do cách các 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 trên trang, chúng tôi thấy việc duy trì giá trị này là không hữu ích.
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ố đó, thì document.characterSet sẽ là chế độ cài đặt hệ thống của người dùng.
Gecko chưa hỗ trợ thuộc tính này và vẫn chưa được chỉ định rõ ràng nên thuộc tính này sẽ không được dùng trong Blink trong Chrome 49 (phiên bản thử nghiệm 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 của bạn cho đến khi tài sản này bị xoá trong Chrome 50:
Bạn có thể đọc thêm nội dung thảo luận về lý do không nêu rõ điều này trên GitHub https://github.com/whatwg/dom/issues/58
Đã xoá getStorageUpdated()
TL;DR: Navigator.getStorageUpdates() đã bị xoá vì không còn trong thông số kỹ thuật của Trình điều hướng.
Ý định xoá Trình theo dõi trạng thái Chrome Vấn đề về CRBug
Nếu việc 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 thông số kỹ thuật HTML5, hãy làm như sau:
Nghe khá thú vị phải không? Thông số kỹ thuật thậm chí còn sử dụng từ "whence" (do xảy ra là trường hợp duy nhất của whence trong thông số kỹ thuật). Ở 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à các cookie. Đồng thời, 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 WebM (và do đó của Blink) không hoạt động.
Nó đã bị xoá khỏi các thông số kỹ thuật một thời gian và bị xoá hoàn toàn khỏi Blink (trong thời gian dài nhất, tính năng này không hoạt động và không có tác dụng 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 đó.
Ngừng sử dụng Object.observe()
Tóm tắt: Ngừng sử dụng Object.observe() vì thuộc tính này không còn trên kênh tiêu chuẩn hoá và sẽ bị xoá trong bản phát hành sau này.
Ý định xoá Trình theo dõi trạng thái Chrome Vấn đề về CRBug
Vào tháng 11 năm 2015, chúng tôi đã thông báo rằng Object.Observe sẽ được rút khỏi TC39. Tính năng này đã ngừng hoạt động trong Chrome 49 và bạn sẽ thấy cảnh báo sau đây trong bảng điều khiển nếu cố sử dụng tính năng này:
Nhiều nhà phát triển thích API này. Nếu bạn đã thử nghiệm API này và đang tìm kiếm đường dẫn chuyển đổi, hãy cân nhắc sử dụng polyfill, chẳng hạn như MaxArt2501/object-quan sát hoặc thư viện trình bao bọc như polymer/observe-js.