Я слышал множество причин, почему бы не использовать кадры HTML, из-за их отсутствия доступности, общего отсутствия в UX, их полностью неэффективного/недостижимого или просто устаревшего.
Все это приводит меня к двум вопросам:
(1) Не по своей сути. iframes имеют много вариантов использования, которые не страдают от проблем с кадрами. Они полезны в любое время, когда вы хотите смешивать документ из другого контекста безопасности или без скриптов и стилей, которые использует родительская страница.
Тем не менее, можно использовать iframe как фрейм: разбить страницу на отдельные области iframe, причем межкадровые ссылки создают навигационный беспорядок, который не очень хорошо работает с закладками, open-in- new-tab и т.д.
(2) Я бы не использовал фреймы для чего-либо сегодня. Для них существовал ограниченный прецедент для хранения большого количества содержимого страницы, которое вы не хотите перезагружать при каждой навигации. Но в наши дни мы просто использовали бы XMLHttpRequest для обновления части страницы.
Тем не менее, не заботясь о том, чтобы сделать доступными страницы для ссылок доступными (используя хэш-историю и имеющую аналог статической ссылки для каждой хэш-ссылки, связанный с реальным <a>, этот ответ на средний клик и др.), страница, которая обновляет/переводит себя с помощью XMLHttpRequest, воссоздает многие навигационные проблемы фреймов с сильно отрицательной практичностью, доступностью и результатами SEO.
Мне немного грустно, что многие авторы создают потрясающие, swooshy, "современные" анимированные веб-сайты, которые наивным образом используют jQuery load() или аналогичные по своему усмотрению, демонстрируют все худшие поведения древних, ненавистных кадров.
(1) Нет. Для iframes существует законное использование, где нет оснований использовать фреймы сегодня с современными браузерами.
(2) Никогда не используйте рамки; существуют и другие более легкие решения, позволяющие получить тот же эффект.
Использовать iframes только в том случае, если встраивание всего сайта является наиболее логичным вариантом. Хотя это редко, иногда бывают случаи, когда это имеет смысл.
Короче говоря, есть причина, по которой теги frame/frameset/noframe выводятся из HTML5, но iframe будет перенесен.
(пример) Если сайт A обязан включать страницу с сайта B (прокси-сервер должен появиться с сайта A), то сайт B css и javascript могут и обычно будут полностью шунтировать сайт A. Это законная причина.
Если по какой-то причине у вас есть "вложенная форма".
Скажите, что у вас есть форма редактирования продукта, и внутри этой формы у вас есть область с другой формой, которая позволяет сказать вам, что вы можете ввести список клиентов для отправки информационного бюллетеня для этого продукта.
Клиенты не связаны с продуктом вообще и не имеют отношения к продукту. Они совместимы с отдельными объектами из продукта.
В этом случае я устанавливаю IFrame с кнопкой добавления клиента и кнопкой отправки, которая отправляет форму внутри IFrame.
Я не нашел лучшего способа реализовать описанный сценарий, чем использовать IFrame. И да, у меня есть требование иметь обе формы на одной странице, а форму бюллетеня следует размещать внутри формы редактирования продукта. Деловая потребность продиктована боссами.
Вы можете использовать iframe, чтобы предоставлять доступ к объявлениям от третьих лиц на вашем веб-сайте, не предоставляя им никакого дополнительного контроля или обмена сообщениями с родительским документом, который содержит iframe.
Таким образом вы предоставляете доступ к объявлениям на своем сайте, но в то же время защищаете от атак из неизвестных ресурсов.
Страницы разработчика mozilla объясняют это лучше:
Элемент HTML представляет собой вложенный контекст просмотра, эффективно вставляя другую страницу HTML на текущую страницу.