Обратная совместимость веб-платформы

Веб-платформа регламентирована как backwards и forwards совместимая.

То есть всё новое, что появляется в платформе не ломает уже имеющееся, и гарантированно должно быть совместимо с будущими изменениями. На деле это вроде как так и есть, но не всегда и не совсем.

Работает это так. Вам вдруг приходит задача, что что-то поломалось в коде. Причём в старом коде, который уже давно не менялся и был написан прото-программистами, которые уже давно уволились. Казалось бы, что может пойти не так? А дело в том, что сами браузеры обновляются и в них что-то вдруг начинает работать по-другому. В том числе код, который вам предстоит исправить. Самые «любимые» баги.

Как это такое происходит, ведь платформа должна быть обратно совместима? Главным образом так: далеко не всегда сначала появляются стандарты, а потом браузеры пилят фичи по этим каноническим стандартам. Иногда фичи просто пропушиваются вендорами (яркий пример — префиксы -webkit-feature, -moz-feature), а потом уже под них подгоняются стандарты или же они адоптятся стандартами и… всё это обратной волной докатывается до браузеров. Браузеры немного меняют имплементацию и ваш код, который просто работал, становится как бы сломанным.

Что поделать, ваш код признан устаревшим и приговаривается к утилизации, приговор обжалованию не подлежит!

Но ок, вендорные префиксы были всеми явно признаны как фейл. Есть и более прозаические примеры.

Есть такой метод play() у аудио и видео HTML-элементов. Он появился ещё в Chrome 3. Он просто работал и включал медиа. То есть можно было запустить, например, видео и тут же его поставить на паузу, чтобы оно сразу прогрузилось.

<script>
  video.play();
  video.pause();
</script>

Потом в Chrome 32 появились Promise. Затем обновились стандарты. И уже в Chrome 50 метод play() стал возвращать промис вместо того, чтобы синхронно выполнить запуск медиа. То есть ваш код сломался и выдаёт эксепшн, который даже даёт ссылку на специальную страничку https://developer.chrome.com/blog/play-request-was-interrupted.

Ещё один пример, немного с другого бока подсвечивает эту же проблему. Люди издревле желали стилизовать скроллбары. Поэтому в Chrome появился целое семейство свойств для стилизации (::-webkit-scrollbar, ::-webkit-scrollbar-track…), в которых можно было задавать ширину или высоту скроллабара (в пикселях!), его цвет фона. Потом это дело ушло вариться в стандарты, ранние черновики были реализованы в Firefox: это были свойства scrollbar-width и scrollbar-color. Причём в scrollbar-width уже нельзя было задавать значения в пикселях (только thin или auto), а scrollbar-color принимал два цвета через пробел (для фонового цвета трека и «таскалки»). И вот так оно и жило где-то с 64 версии FF до наших дней: для стилизации в FF использовался «правильный» вариант с scrollbar-width/scrollbar-color, а в Chrome работали вендорные префиксы.

Что же могло пойти не так? В Chrome 121 завезли (https://developer.chrome.com/docs/css-ui/scrollbar-styling) так же стандартные scrollbar-width и scrollbar-color! И ваш код, хоть и не упал, но начал работать по-другому, так как скроллбары стали другими, и хорошо, если просто стали другими. В целом не то чтобы критично. Но возможно сегодня где-то в далёком офисе одинокий разработчик сдувает пыль с давнего проекта и добавляет хак, чтобы всё оставалось как раньше, и в Chrome по-прежнему применялась только стилизация через вендорные префиксы:

@media screen and (min--moz-device-pixel-ratio: 0) {
  .scrollable_styled {
    scrollbar-width: thin;
    scrollbar-color: gray transparent;
  }
}

.scrollable_styled::-webkit-scrollbar {
  width: 8px;
}

.scrollable_content::-webkit-scrollbar-thumb {
  background-color: gray;
}

Directed by robert b weide 🥁

А для тех, кто дочитал до конца, приятный бонус: список задепрекейченых и выпиленных платформенных API: JS, HTML, CSS.