Веб-платформа регламентирована как 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.