Развитие современной веб-платформы определяется непрерывным соревнованием двух ведущих браузерных движков: Blink (Google Chrome) и WebKit (Apple Safari). С одной стороны, инженеры стремятся ускорить доставку контента и стандартизировать эффективные форматы медиаданных. С другой стороны, появление новых физических форм-факторов — от ультрашироких мониторов до складных смартфонов с двумя экранами — подвергает суровому испытанию устоявшиеся правила верстки и обнажает закрытые эвристики рендеринга. В этом тематическом выпуске сопоставляем прогрессивные медиастандарты в Chrome 155 с практическими подводными камнями отображения страниц в Safari на складных экранах.
Новинки Chrome 155
Команда Chromium выпустила стабильную ветку Chrome 155, сделав важный шаг навстречу открытым графическим стандартам. Главным событием релиза стало долгожданное возвращение нативной поддержки формата изображений JPEG XL (JXL). Несколько лет назад Google удалил экспериментальный код поддержки JXL из кодовой базы, однако давление индустрии, консорциума W3C и участие в совместной программе Interop 2026 вернули формат на флагманские позиции, о чем подробно рассказывалось в обзоре релиза Chrome 155.
Формат JPEG XL сочетает преимущества нескольких поколений сжатия:
- Поддержка сжатия без потерь (lossless) и с потерями (lossy), превосходящая WebP и AVIF по сохранению микротекстур;
- Аппаратное ускорение декодирования на современных GPU;
- Возможность сжатия существующих файлов JPEG на 20% без малейшей потери визуальной информации (lossless transcoding);
- Нативная поддержка широкого динамического диапазона (HDR) и расширенного цветового охвата Rec. 2020.
Вторым концептуальным новшеством стала стандартизация элемента <poster> внутри видеоплеера рабочей группой WHATWG HTML. Исторический атрибут poster="preview.jpg" в теге <video> был серьезным ограничением: он не поддерживал атрибуты srcset и sizes, заставляя мобильные устройства загружать тяжелые десктопные обложки. Новый дочерний элемент <poster> позволяет декларировать адаптивные источники через <source> и добавлять атрибут alt, критически важный для доступности (accessibility / a11y) и снижения задержки первого осмысленного кадра (LCP):
<!-- Адаптивная заставка для видеоплеера с поддержкой формата нового поколения -->
<video controls width="800" class="responsive-player">
<poster>
<source srcset="poster-mobile.jxl" type="image/jxl" media="(max-width: 600px)">
<source srcset="poster-desktop.jxl" type="image/jxl">
<source srcset="poster-fallback.webp" type="image/webp">
<img src="poster-default.jpg" alt="Превью технического доклада по архитектуре">
</poster>
<source src="presentation.mp4" type="video/mp4">
Ваш браузер не поддерживает элемент видео.
</video>
Параллельно в экосистеме стартовало альфа-тестирование Bootstrap 6, где авторы начали постепенный отказ от устаревших CSS-переменных в пользу нативных математических функций веб-платформы.
Однако если оптимизация медиаформатов в движке Blink делает веб быстрее и предсказуемее, то столкновение адаптивной верстки с закрытыми эвристиками интерфейсов Apple вскрывает совершенно иной класс проблем.
Safari на складных экранах
Выход предварительных сборок симулятора складного двухэкранного смартфона iPhone Duo в составе Xcode 27.1 RC вызвал бурное обсуждение среди фронтенд-инженеров. Внимание сообщества привлекла публикация Майка Пионтека (Mike Piontek), в которой детально разобраны скрытые проблемы рендеринга движка WebKit в мобильном Safari.
Первый серьезный сбой касается механизма безопасных зон (Safe Area Insets). Исторически переменные env(safe-area-inset-*) защищали контент от наложения на «челку» (notch) или вырез Dynamic Island. Однако на складном экране iPhone Duo браузер Safari размещает собственную вертикальную панель инструментов справа от экрана и при этом… не сообщает веб-странице о необходимости отступа через env(safe-area-inset-right). Переменная возвращает 0px. В итоге любые полноэкранные фиксированные шапки (position: fixed) оказываются жестко перекрыты и обрезаны интерфейсом браузера.
Вторая проблема — недокументированная эвристика интерфейсного оформления Liquid Glass. Safari игнорирует декларативный метатег <meta name="theme-color"> и самостоятельно выбирает цвет подложки панели, сканируя пиксели в узкой полосе шириной 5–10 px от соответствующего края страницы:
- Выборка работает только для элементов со свойствами
position: fixedилиsticky; - Хак, традиционно использовавшийся для Mac Safari (добавление зеленой декоративной полоски в 5px сверху страницы), на iPhone Duo приводит к катастрофе: на двухэкранном устройстве Safari берет пробу цвета с правого края, и добавление полоски вызывает паразитный горизонтальный скролл страницы.
Для предотвращения визуальных артефактов фиксированные шапки требуют осторожного оборачивания в условные правила с явным запасом под системные панели:
/* Безопасное позиционирование фиксированной шапки с учетом зон WebKit */
.site-header {
position: fixed;
top: 0;
left: 0;
width: 100%;
/* Компенсируем верхние и боковые безопасные зоны */
padding-top: env(safe-area-inset-top, 12px);
padding-right: max(env(safe-area-inset-right, 0px), 16px);
padding-left: max(env(safe-area-inset-left, 0px), 16px);
/* Единый фоновый цвет для стабильной выборки Liquid Glass */
background-color: #1e293b;
box-sizing: border-box;
z-index: 1000;
}
Сопоставление двух новостей подчеркивает фундаментальную закономерность эволюции веб-платформы: с одной стороны, движение в сторону аппаратно ускоренного JPEG XL и нативного элемента <poster> в Chromium дает разработчикам мощные легальные инструменты сокращения трафика и улучшения показателей Core Web Vitals. С другой стороны, попытки вендоров скрыть интерфейс браузера за автоматическим подбором цветов и размытием фона (как в Liquid Glass от Apple) часто ломают стандартную CSS-блочную модель.
В эпоху появления сложных устройств с гибкими и складными дисплеями фронтенд-командам необходимо заранее тестировать свои дизайн-системы в официальных эмуляторах, закладывая защитные отступы через max() и не полагаясь на то, что браузер корректно рассчитает геометрию экрана самостоятельно.