Почему разработчики ненавидят фреймы? [дубликат]


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

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

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

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

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

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

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

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

16 52

16 ответов:

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

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

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

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

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

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

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

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

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

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

одной из причин является безопасность -- iframe инъекции атаки были довольно распространены. Увидеть этот адрес электронной почты страницы описание:

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":

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

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

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

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

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

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

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

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

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

HTML-элементы не должны иметь поведение.

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

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

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