Почему разработчики ненавидят iframe?

Возможный дубликат:
Являются ли iframes считающимися "плохой практикой" ?

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

И когда я сказал своему предыдущему боссу "не разработчику", что однажды я буду использовать iframe, он посмотрел на меня как на плохого разработчика:)

Что я хочу знать, имеет ли iframes очень плохую историю с веб-разработкой?

Это катастрофа?

В некоторых случаях я вижу, что он должен использовать iframes, говорит, что означает, что я плохой разработчик?

Или все из-за этого трудно справиться из-за некоторых проблем безопасности, о которых мы должны заботиться при разработке?

Пожалуйста, перечислите свои баллы, если вы слишком ненавидите или меня исправите, если я думаю неправильно.

Ответ 1

В iframe могут быть аналогичные проблемы с фреймами и необоснованное использование XMLHttpRequest: они разбивают парадигму с одним документом на URL, которая необходима для правильного функционирования Интернета (думаю, закладки, глубокие ссылки, поисковые системы,...).

Если вы создаете веб-приложение, используйте любой метод, который вы хотите (включая фреймы, флеш, апплеты, $any). Если вы создаете реальную информационную веб-страницу, придерживайтесь бескаркасных HTML, CSS и ненавязчивых Java-скриптов и имейте в виду, что страница должна по-прежнему использоваться при отключении сценариев.

Ответ 2

Как сказал Носредна, это, вероятно, потому, что люди путают их с фреймами, и на самом деле есть много действительных аргументов против фреймов. Некоторые из них не применимы к iframes, но опять же некоторые из них.

Самая яркая проблема, вероятно, связана с глубокой привязкой: верно, что iframes страдают от этого в меньшей степени, чем фреймы, но если вы позволяете своим пользователям перемещаться между разными страницами в iframe, это будет проблемой. Там также пара проблем с юзабилити, которые вам придется соблюдать. Наиболее распространенным примером является двойная полоса прокрутки, которую я лично считаю невероятно раздражающей.

Я стараюсь избегать iframes, главным образом потому, что считаю его нечетким решением. Я обнаружил, что, когда я действительно сажусь и думаю об этом, почти всегда есть лучшее решение. Несмотря на это, я также считаю, что для них есть место. Это переживание мира в Интернете: просто потому, что у него есть история злоупотребления, он стал консенсусом в отношении того, что его никогда не следует использовать. Это действительно не так, но я верю, что вы должны подумать дважды, прежде чем использовать iframes.

Ответ 3

Я хотел добавить, что большую часть времени iframe не помогает SEO странице. Googlebot не помещает содержимое iframe на страницу.

Ответ 4

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

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

Ответ 5

Я думаю, что люди путают iframes с фреймами HTML, а фреймы довольно презрительно.

Люди постоянно используют iframe, даже не осознавая этого. Если я правильно помню, TinyMCE использует iFrames.

Ответ 6

Одной из причин является безопасность - атаки инъекций iframe были довольно распространены. См. Эту страницу Ars Technica для описания:

http://arstechnica.com/security/news/2008/03/ongoing-iframe-attack-proving-difficult-to-kill.ars

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

http://www.thespanner.co.uk/2007/10/24/iframes-security-summary/

С другой стороны, они обеспечивают междоменную связь и обычно используются "ajaxy" webapps:

http://softwareas.com/cross-domain-communication-with-iframes

Ответ 7

Одна из проблем заключается в том, что они имеют собственный жизненный цикл страниц, поэтому интерактивность между дочерним узлом и дочерним элементом iframe ограничена (строка запроса, переменные сеанса или JS). Альтернативой было бы рассмотреть использование прокручиваемого div.

Другой проблемой является печать. Вывод iframe (или прокрутки div в этом случае) может быть непредсказуемым и сильно варьироваться между разными браузерами.

Ответ 8

В iframe нет ничего плохого для создания веб-приложений. Они позволяют сочетать целевой контент с инкапсуляцией памяти. Сколько раз кто-то создавал какую-то небольшую небольшую javascript-ajax-вещь, которая полностью поглощала куски, когда они забывали и загружали последнюю Jlibrary на свою родительскую страницу или на какой-то загруженный контент DIV? Большинство других вопросов окружают SEO, которые имеют значение только в том случае, если вы на самом деле хотите украсть контент кого-то elses, который в любом случае является довольно глупым. Iframes дают вам инкапсулированную память и возможность совместно использовать хорошо разработанные страницы на нескольких сайтах. Несмотря на то, что многие могли бы поверить, Iframes и их эквиваленты будут в течение очень долгого времени.

Ответ 9

iframe of today имеют плохое имя из-за поддержки iframe в прошлых браузерах. Подобно VB.NET, имеющему плохой рэп из-за истории VB6. Я использую их в эти дни там, где это необходимо... просто имейте в виду, что это возможно для того, чтобы он не работал так, как вы планировали, время от времени, и объяснять это.

Ответ 10

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

Ответ 11

Я думаю, что у IFrames есть свое место. Я не буду использовать их на внешних/публичных веб-сайтах из-за проблем с SEO и т.д. Для внутреннего/внутреннего веб-приложения я считаю, что они полезны, когда вам нужно изолировать стиль определенного раздела от остальной части страницы, например средство просмотра отчетов или редактор HTML, где унаследованные стили с родительской страницы могут вызвать проблему, если весь контент находится в одном документе. Мой 2c...

Ответ 12

Я думаю, потому что это противоречит всему фундаментализму html-contents-contents + css-does-the-visual-design. Кроме того, чрезмерное использование iframe является потерей производительности, поскольку он делает отдельные вызовы для извлечения кадра. Если вы думаете об этом, AJAX в основном похож на iframe, за исключением его модного сегодня (может и не быть в будущем).

Безопасность, это своего рода проблематично, потому что пользователь может загружать полную дерьмо из другого домена, даже не зная.

Ответ 13

Элементы HTML не должны иметь поведения.

Ответ 14

Потому что с ними может быть сложно работать, когда дело касается безопасности. Хороший, современный браузер не позволяет писать код в iFrame, который манипулирует элементами в других iFrames на странице. Это может иногда затруднить определенные методы.

Ответ 15

Вы не должны использовать iframes для дизайна. CSS делает лучшую работу для одного и того же и позволяет намного больше свободы.

Ответ 16

Это плохая практика, и ленивый способ писать хорошо (читайте: делает то, что хотел клиент). Поиск "iframe bad" в Google (без кавычек) вызывает много дискуссий на форуме по этой теме. Если вам действительно нужно использовать внешний контент, используйте AJAX. Еще лучше, не делайте этого вообще.