Считают ли iframes «плохой практикой»? [закрыто]

В какой-то момент я понял, что использование фреймов - «плохая практика».

Это правда? Каковы плюсы / минусы их использования?

Как и во всех технологиях, у него есть свои взлеты и падения. Если вы используете iframe, чтобы обойти правильно разработанный сайт, то, конечно, это плохая практика. Однако иногда iframe является приемлемым.

Одна из основных проблем с iframe связана с закладками и навигацией. Если вы используете его для простого встраивания страницы в ваш контент, я думаю, это нормально. Вот для чего нужен iframe.

Тем не менее, я также видел злоупотребления фреймами. Он никогда не должен использоваться как неотъемлемая часть вашего сайта, но как часть контента на сайте.

Обычно, если вы можете сделать это без iframe, это лучший вариант. Я уверен, что другие здесь могут иметь больше информации или более конкретных примеров, все это сводится к проблеме, которую вы пытаетесь решить.

С учетом вышесказанного, если вы ограничены HTML и не имеете доступа к бэкэнду, такому как PHP, ASP.NET и т. Д., Иногда iframe - ваш единственный вариант.

Это не плохая практика, это просто еще один инструмент, который добавляет гибкости.

Для использования в качестве стандартного элемента страницы ... они хороши, потому что это простой и надежный способ разделения контента на несколько страниц. Особенно для сгенерированного пользователем контента, может быть полезно «замкнуть» внутренние страницы в iframeнастолько плохую разметку, которая не повлияет на главную страницу. Недостатком является то, что если вы введете несколько уровней прокрутки (один для браузера, другой для iframe), ваши пользователи будут разочарованы. Как сказал adzm, вы не хотите использовать iframeпервичную навигацию, но думаете о них как о тексте / разметке, эквивалентной способу встраивания видео или другого медиа-файла.

Для сценариев фоновых событий, выбор обычно между скрытым iframeи XmlHttpRequestзагружать контент для текущей страницы. Разница в том, что он iframeгенерирует загрузку страницы, поэтому вы можете перемещаться назад и вперед в кеше браузера с большинством браузеров. Обратите внимание, что Google, который использует XmlHttpRequestповсеместно, также использует iframes в некоторых случаях, чтобы позволить пользователю перемещаться назад и вперед в истории браузера.

Это «плохая практика» - использовать их, не понимая их недостатков. Пост Adzm очень хорошо их подводит.

С другой стороны, gmail интенсивно использует iFrames в фоновом режиме для некоторых из своих более прохладных функций (таких как автоматическая загрузка файлов). Если вы знаете об ограничениях iFrames, я не думаю, что вы должны испытывать какие-либо затруднения при их использовании.

Работая с ними во многих обстоятельствах, я действительно пришел к выводу, что iframe - это веб-программирование, эквивалентное выражению goto. То есть чего-то, чего вообще следует избегать. На сайте они могут быть несколько полезны. Тем не менее, кросс-сайт, они почти всегда плохая идея для всего, кроме самого простого контента.

Рассмотрим возможности ... если они используются для параметризованного контента, они создали интерфейс. А на профессиональном сайте этот интерфейс требует SLA и управления версиями - которые почти всегда игнорируются при выходе в Интернет.

Если используется для активного контента - фреймов, в которых размещен скрипт - тогда существуют (разные) ограничения междоменного скрипта. Некоторые могут быть взломаны, но редко последовательно. И если ваш контент в рамке нуждается в интерактивности, он будет изо всех сил делать это за рамками.

При использовании с лицензионным контентом участвующие сайты обременены необходимостью перемещать информацию о правах вне хостов.

Таким образом, хотя иногда они полезны для сайта, они не подходят для коллажей. Ты гораздо лучше смотришь на настоящие порталы и портлеты. Хуже того, они любимы любителями веб-технологий - многие технические менеджеры используют их для решения многих проблем. На самом деле они создают больше.

Исходя из моего опыта, положительной стороной для iframe является вызов сторонних кодов, который может включать в себя вызов javascript, который вызывает Document.write();команду a . Как вы, возможно, знаете, эти команды нельзя вызывать асинхронно из-за того, как они анализируются (DOM Parser и т. Д.). Примером этого является http://sourceforge.net/projects/phpadsnew/ Я использовал iframes, чтобы ускорить наш сайт, так как было несколько обращений к phpadsnews, и сайт ждал ответа, прежде чем приступить к визуализации других. части страницы. с помощью iframe я смог разрешить сайту отображать другие части страницы и по-прежнему вызывать Document.write()команду phpads асинхронно. Предотвращение и блокировка js.

Есть определенно использование для людей iframes. Как еще вы могли бы разместить виджет погодных сетей на своей странице? Единственный другой способ - это захватить их XML и проанализировать его, но тогда, конечно, вам нужны условия, чтобы вывести постоянную графику погоды ... не очень стоит, но намного чище, если у вас есть время.

Оригинальная модель frameset (Frameset и Frame-elements) была очень плохой с точки зрения удобства использования. IFrame был более поздним изобретением, в котором не было столько проблем, как в оригинальной модели фрейм-набора, но у него был недостаток.

Если вы разрешите пользователю перемещаться внутри IFrame, тогда ссылки и закладки не будут работать должным образом (потому что вы добавляете в закладки URL-адрес внешней страницы, но не URL-адрес iframe).

Когда ваша главная страница загружается по протоколу HTTP, а части вашей страницы должны работать по протоколу HTTPS, iFrame может опередить jsonp.

Особенно, если ваш dataType изначально не является json и должен быть переведен на сервере в json и переведен на клиенте обратно, например, в сложный html.

Так что нет - iFrame это не зло.

Они не плохие, но на самом деле полезные. Некоторое время назад у меня была огромная проблема, когда мне приходилось вставлять свой твиттер, и он просто не позволял md делать это на той же странице, поэтому я установил его на другой странице и вставил как iframe.

Они также хороши, потому что все браузеры (и браузеры телефонов) поддерживают их. Они не могут считаться плохой практикой, если вы используете их правильно.

Стоит отметить, что iframes будет, независимо от скорости интернет-соединения ваших пользователей или содержимого iframe, вызывать небольшое (0,3 с или около того), но заметное снижение скорости загрузки вашей страницы. Это не то, что вы увидите при локальном тестировании. На самом деле, это верно для любого элемента, добавляемого на страницу, но фреймы кажутся хуже.

Я видел успешное применение IFRAME как простого способа создания динамических контекстных меню, но целевой аудиторией этого веб-приложения были только пользователи Internet Explorer.

Я бы сказал, что все зависит от ваших требований. Если вы хотите, чтобы ваша страница работала одинаково хорошо во всех браузерах, избегайте использования IFRAME. Если вы нацелены на узкую и хорошо известную аудиторию (например, на локальную интрасеть) и видите выгоду в использовании IFRAME, то я бы сказал, что это нормально.