Практически в каждой версии Chrome мы видим значительное количество обновлений и улучшений продукта, его производительности, а также возможностей веб-платформы.
В Chrome 49 (бета-версия, 2 февраля 2016 г. Предполагаемая дата выхода версии: март 2016 г.) в Chrome имеется ряд изменений.
Использование префикса «css» в getComputedStyle(e).cssX устарело.
TL;DR : использование префикса «css» в getComputedStyle(e) устарело, поскольку оно не было частью формальной спецификации .
getComputedStyle — отличная маленькая функция. Он вернет все значения CSS стилей элемента DOM, вычисленные механизмом рендеринга. Например, вы можете запустить getComputedStyle(_someElement_).height , и он может вернуть 224,1 пикселя, поскольку это высота элемента, отображаемого в данный момент.
Кажется, довольно удобный API. Так что же мы меняем?
До того, как механизм рендеринга Chrome был заменен на Blink, он работал на базе WebKit, что позволяло добавлять префикс «css» в начало свойства. Например getComputedStyle(e).cssHeight вместо getComputedStyle(e).height . Оба будут возвращать одни и те же данные, поскольку они сопоставлены с одними и теми же базовыми значениями, но именно такое использование префикса «css» является нестандартным, было объявлено устаревшим и удалено.
Примечание. cssFloat является стандартным свойством, и на него не влияет это устаревание.
Если вы таким образом получите доступ к свойству в Chrome 49, оно вернет undefined , и вам придется исправить свой код.
Использование initTouchEvent устарело.
TL;DR : initTouchEvent устарел в пользу constructor TouchEvent для улучшения соответствия спецификациям и будет полностью удален в Chrome 54.
Намерение удалить проблему CRBug в Chromestatus Tracker
В течение долгого времени вы могли создавать синтетические события касания в Chrome с помощью API initTouchEvent . Они часто используются для имитации событий касания либо для тестирования, либо для автоматизации некоторого пользовательского интерфейса на вашем сайте. В Chrome 49 мы объявили устаревшим этот API и будем отображать следующее предупреждение с намерением полностью удалить его в Chrome 53.
Есть ряд причин, почему это изменение хорошо . Его также нет в спецификации Touch Events. Реализация initTouchEvent в Chrome вообще не была совместима с API-интерфейсом initTouchEvent в Safari и отличалась от Firefox на Android. И, наконец, конструктор TouchEvent намного проще в использовании.
Было решено, что мы будем стремиться следовать спецификации, а не поддерживать API, который не является ни спецификациями, ни совместимыми с единственной другой реализацией. Следовательно, мы сначала объявляем устаревшей, а затем удаляем функцию initTouchEvent и требуем от разработчиков использовать конструктор TouchEvent .
Этот API используется в Интернете, но мы знаем, что он используется относительно небольшим количеством сайтов, поэтому мы не удаляем его так быстро, как обычно. Мы полагаем, что некоторые возможности использования нарушены из-за того, что сайты не поддерживают версию подписи Chrome.
Поскольку реализации API initTouchEvent для 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» в User-Agent, и Chrome на Android будет соответствовать этому устаревшему значению. Однако его пока нельзя удалить, поскольку в течение некоторого времени на Android будут существовать другие браузеры на базе WebKit и более старые версии Blink, в которых вам все равно потребуется поддержка старого API.
Чтобы правильно обрабатывать TouchEvents в Интернете, вам следует изменить свой код для поддержки Firefox, IE Edge и Chrome, проверив наличие TouchEvent в объекте window и имеет ли он положительную «длину» (что указывает на то, что это конструктор, принимающий аргумент). ) вам следует это использовать.
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
TL;DR: методы WebRTC RTCPeerConnection createOffer() и createAnswer() теперь требуют обработчика ошибок, а также обработчика успеха. Раньше эти методы можно было вызывать только с помощью обработчика успеха. Такое использование устарело.
В Chrome 49 мы также добавили предупреждение, если вы вызываете setLocalDescription() или setRemoteDescription() без предоставления обработчика ошибок. Мы ожидаем, что аргумент обработчика ошибок станет обязательным для этих методов в Chrome 50.
Это часть расчистки пути для введения промисов в эти методы, как того требует спецификация 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 устарел.
TL;DR : Document.defaultCharset устарел для улучшения соответствия спецификациям.
Намерение удалить проблему CRBug в Chromestatus Tracker
Document.defaultCharset — это свойство, доступное только для чтения, которое возвращает кодировку символов по умолчанию в системе пользователя в зависимости от его региональных настроек. Сохранять это значение оказалось бесполезным из-за того, что браузеры используют информацию о кодировке символов в ответе HTTP или в метатеге, встроенном в страницу.
Используя document.characterSet, вы получите первое значение, указанное в заголовке HTTP. Если его нет, вы получите значение, указанное в атрибуте charset элемента <meta> (например, <meta charset="utf-8"> ). Наконец, если ни один из них недоступен, document.characterSet будет системной настройкой пользователя.
Gecko не поддерживает это свойство, и оно не указано четко, поэтому оно будет прекращено из Blink в Chrome 49 (бета-версия в январе 2016 г.). Следующее предупреждение будет появляться в вашей консоли до тех пор, пока свойство не будет удалено в Chrome 50:
Более подробное обсуждение причин не указывать это можно прочитать на github https://github.com/whatwg/dom/issues/58 .
getStorageUpdates() удален.
TL;DR : Navigator.getStorageUpdates() был удален, поскольку его больше нет в спецификации Navigator .
Намерение удалить проблему CRBug в Chromestatus Tracker
Если это кого-то затронет, я съем свою шляпу. getStorageUpdates() почти никогда (если вообще) не использовался в сети.
Процитируем (очень старую версию) спецификации HTML5:
Звучит довольно круто, правда? В спецификации даже используется слово «откуда» (которое случайно является единственным примером «откуда» в спецификации). На уровне спецификации существовал StorageMutex , который контролировал доступ к блокирующим хранилищам, таким как localStorage и файлы cookie, и этот API помогал освобождать этот мьютекс, чтобы другие сценарии не блокировались этим StorageMutex . Но он так и не был реализован, не поддерживается в IE или Gecko, а реализация в WebKit (и, следовательно, в Blink) так и не была реализована.
Его уже давно удалили из спецификаций и полностью удалили из Blink (долгое время он не работал и ничего не делал, даже если его вызвать).
В том маловероятном случае, если у вас есть код, вызывающий navigator.getStorageUpdates() , вам придется проверить наличие функции перед ее вызовом.
Object.observe() устарел
TL;DR : Object.observe() устарел, поскольку он больше не находится на стадии стандартизации и будет удален в будущем выпуске.
Намерение удалить проблему CRBug в Chromestatus Tracker
В ноябре 2015 года было объявлено, что Object.Observe выводится из TC39 . Он устарел в Chrome 49, и если вы попытаетесь его использовать, в консоли вы увидите следующее предупреждение:
Многим разработчикам понравился этот API, и если вы экспериментировали с ним и теперь ищете путь перехода, рассмотрите возможность использования полифила, такого как MaxArt2501/object-observe , или библиотеки-оболочки, такой как полимер/observe-js .