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