Адаптивные iframe в Chrome 154: высота по содержимому с согласия обеих страниц
Новая возможность устраняет часть ручного обмена размерами через postMessage. Но встроенная страница должна явно разрешить изменение размеров, а динамические обновления требуют обращения к requestResize.
Откуда берётся вторая полоса прокрутки
У iframe есть собственная область просмотра. Если виджет комментариев становится выше выделенного прямоугольника, внутри страницы возникает ещё одна прокрутка. Раньше разработчики часто измеряли содержимое встроенного документа, отправляли высоту родительской странице и меняли размеры через JavaScript. Материал Chrome от 16 сентября описывает новый механизм Chrome 154, стабильный выпуск которого состоялся 22 сентября. Родитель задаёт frame-sizing, а браузер использует внутренний размер документа. Это возможность определённого выпуска, а не автоматическое исправление всех существующих вставок.
Встраиваемая страница тоже участвует
Для типичного вертикального виджета используется content-height. Внутри iframe нужен meta responsive-embedded-sizing с разрешёнными источниками. Документация предупреждает, что добавлять этот тег динамически после загрузки недостаточно. Для сторонней вставки это важное условие: владелец сайта не может в одностороннем порядке заставить любой чужой документ раскрывать размеры через новый механизм. Можно ограничить перечень разрешённых origins. Такая настройка дополняет другие правила встраивания; она не заменяет Content Security Policy и не даёт странице произвольного доступа к чужому DOM. Логические значения content-inline-size и content-block-size описывают размеры относительно направления письма, а content-width и content-height используют физические оси. Такое различие важно для документов с другой ориентацией текста. Встроенная страница также может разрешить несколько origins, перечисленных в meta. Это список участников изменения размеров, а не правило чтения её содержимого. Обычная политика происхождения и ограничения встраивания продолжают действовать независимо; новый механизм согласует геометрию, не объединяя два документа в один DOM.
Динамика обновляется явно
Браузер не превращается в непрерывный наблюдатель за каждой переменой внутри документа. После загрузки дополнительных комментариев или раскрытия панели встроенная страница может вызвать window.requestResize. Явная модель помогает избежать циклов, когда новый размер изменяет вёрстку, та вызывает ещё один размер, и процесс повторяется. Это означает, что интеграция затрагивает сценарии обновления содержимого. Одной декларации в CSS недостаточно, если виджет меняется после начальной загрузки. Поведение следует проверить при длинных строках, изображениях и изменении ширины родительского окна.
Размер по содержимому тоже имеет ограничения
Документация перечисляет варианты для физической ширины, высоты и логических размеров. Значение auto сохраняет прежнее поведение. Разрешено сочетать новую возможность с ограничениями CSS, например максимальной высотой. При этом встраивание может сдвигать содержимое основного документа, особенно если находится в первом экране и загружается поздно. Поэтому исчезновение внутренней полосы прокрутки не гарантирует улучшения всех метрик: необходимо учитывать визуальную стабильность, резервирование места и фактическую последовательность загрузки. Страница с несколькими вставками особенно чувствительна к их суммарным изменениям.
Что сохраняется для остальных браузеров
Официальный пример предлагает проверку поддержки через @supports и наличие requestResize. Резервная фиксированная высота или существующий способ обмена размерами может продолжить работу там, где новый API отсутствует. Это даёт возможность внедрять изменение постепенно. Сам черновик CSS Sizing описывает модель размеров и имеет статус развивающегося документа, поэтому его нельзя приравнивать к таблице фактической поддержки. Для готовой интеграции важно отдельно проверить основной сайт и поставщика виджета: оба должны участвовать в протоколе, а пользователь должен сохранить доступ ко всему содержимому при любом поддерживаемом варианте.
