Я создаю виджет, и я использую iframe для представления содержимого в нем. В какой-то момент я могу начать обслуживать сторонний HTML и JS, поэтому я подумал, что iframes будет хорошей идеей.Являются ли iframes ужасной идеей?
Это делает javascript-виджет немного более сложным, и я обеспокоен тем, что это может быть не лучшая реализация.
У вас есть совет? Было бы огромной помощью узнать, что другие люди думают об iframes.
Нет, ничего неправильного в iframe. Iframe, вероятно, лучше, если вы собираетесь запускать сторонний контент.
Предстоящая спецификация HTML5 также планирует создавать дополнительные функции безопасности в iframe для таких ситуаций, поэтому я бы счел целесообразным использовать их сейчас.
Зависит от того, что делает виджет. Iframes имеют свое место, но они действительно вызывают несколько головных болей (не говоря уже о том, чтобы сделать ваши js более сложными), поэтому большинство людей склонны избегать их, если это абсолютно необходимо.
Недавно я обнаружил, что .aspx-страницы, встроенные внутри iframe иногда имеют проблемы с потерей файлов cookie, что привело к потере состояния сеанса в приложении, с которым я был связан.
Для меня это было в сценарии, когда другой магазин разработки потреблял одну из моих .aspx страниц на их собственной странице. Это означает, что мы находимся на отдельных серверах, что может быть или не быть заметным.
По-видимому, это было вызвано тем, что родительская страница отклонила файлы cookie для дочерней страницы ... Так же, как и в cookie сеанса, так происходит сеанс.
Конкретными механика, как это работает немного вовлечены: More Details
Эта проблема не влияет на FireFox, но это показать в IE7, и это была настоящая загадка в течение нескольких часов.
Кроме того, я должен противоречить статье I, связанной сверху с одной точкой. В статье говорится, что вы не получите это, если содержащая страница также является .aspx ... В этом случае это было неверно, потому что обе страницы были .aspxs.
Это ставит под сомнение все остальное, о чем говорится в статье об этой ситуации, но это привело к разрешению, так что это тоже что-то.
В статье предложено, я вставил следующий код, который впрыскивает P3P (Конфиденциальность Preferences Project - Я никогда не слышал об этом) заголовок в данной страницы Init событие:
HttpContext.Current.Response.AddHeader("p3p", "CP=\""IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\""")
... И что фиксировало проблему.
iframe, как и кадры, являются просто элементами управления, которые можно использовать для этой задачи. Таким образом, он не является ни хорошим, ни плохим сам по себе, но может быть хорошим или плохим на основе поставленной задачи и требований клиента. Насколько мне известно, все современные браузеры (и не-linux-пользователи) смогут «видеть и потреблять» iframe без проблем.
Хорошим вариантом является использование свойства CSS переполнения. Значение по умолчанию отображается, но вы можете настроить его на скрытый, прокручиваемый или автоматический. Я бы использовал авто в вашем случае. Если ваш контент становится слишком большим, он будет выглядеть так, как будто у вас есть iframe, но он по-прежнему остается на странице.
Не обязательно, до тех пор, пока содержание в пределах фрейма предсказуем.
Перед тем, как XMLHTTPRequest стал широко использоваться, люди использовали комбинацию JavaScript и iframe для динамического воспроизведения контента, не обновляя полную страницу.
Существует много информации о разработке сайтов таким образом, чтобы у вас было относительно простое время, чтобы найти обходное решение для многих коряг, которые вы, скорее всего, ударите.
Единственное, что я обнаружил, что это боль, - это междоменное использование JavaScript в iframe. Если страница, которую вы внедряете в iframe, находится в другом домене, чем «родительская» страница, браузеры имеют ограничения безопасности, позволяющие вам получить доступ к одному из другого. Хитрость заключается в том, что обе страницы объявляют
document.domain = 'somedomain.com';
В этом обходном пути есть много материала.
Удачи вам!
Я считаю, что они могут только изменить document.domain, чтобы быть доменом более высокого уровня - т. Е. Www.acme.com может изменить домен на acme.com, но не на google.com. Таким образом, это только помогает iframes обмениваться данными между субдоменами одного домена. (Я мог ошибаться, но это то, что я помню) – Josh
@Josh - вы правы, document.domain будет работать только для страниц в одном и том же родительском домене, но в разных субдоменах. –
@Josh Вы правы, но всегда можете использовать 'window.location.href'. – nyuszika7h
Лично я бы избегал этого , если вы можете без лишних хлопот. Используя Javascript (или AJAX, если вам нужно загружать их динамически), вы можете просто просто использовать div и изменять содержимое по мере необходимости - в некоторых случаях это даст вам гораздо большую гибкость и упростит вашу JS, особенно если есть много взаимодействия вашего виджета с остальной частью страницы.
Это говорит о том, что я изучил оба варианта, и если путь JS кажется слишком сложным или сложным, просто перейдите к iframes.
Есть только одна «очень плохая» вещь с ними, о которой я знаю.
Если третья сторона делает некоторые JavaScript, что попытки изменить их DOM немного слишком рано ... IE6 и IE7 отбросит о так бесполезные «Operation Aborted» ошибка, то пустой не только в IFRAME, но вся окружающая страница. (например, ваш сайт не отображается)
В IE8 он не исправлен, но сбой лучше обрабатывается.
По моему опыту, iframe - это либо хаки, либо таймеры - убедитесь, что если вы используете их, они необходимы по этим причинам. Если у вас есть контроль над содержимым (или вы можете получить контроль посредством зеркалирования или скребков), вы должны рассмотреть возможность использования AJAX или серверной части, чтобы вытащить внешние данные и оттолкнуть ее от страницы - в итоге она станет более гибкой, более прочную и удобную в управлении.
Технически нет ничего плохого в iFrame, что с альтернативами. Но семантически, есть зло.
Веб основан на протоколе HTTP, который говорит, что данный URL-адрес всегда приведет к уникальному ресурсу.
Используя iFrame, вы просто обслуживаете несколько ressources, расплавленных на веб-страницах за одним URL для всех из них. Если у вас есть опасения по поводу того, как должен развиваться Интернет, это хлопотно. Более того, для роботов поисковой системы это сложно.
Я собираюсь не согласиться с большинством голосов и сказать, что да, iframes являются абсолютно ужасно идея. Любой, кто некоторое время работал в сообществе веб-дизайна, согласен с тем, что iframe являются чистым злом, и его следует избегать, если АБСОЛЮТНО существенным.
Мои причины полагать, что они плохи, потому что они нарушают навигационную схему веб-страницы. Используя iframe, вы можете эффективно сломать кнопки назад и вперед в браузерах и запутать своих пользователей. Это нарушает всю идею протокола HTTP; что URL-адрес всегда приведет к уникальному местоположению. Если бы iframe был лошадью, он давно бы удалился. Существуют и другие способы динамического обслуживания контента, и они должны использоваться вместо этого.
Если вы создаете виджет то непосредственные проблемы с использованием фреймов исчезают (плохо для поисковых систем, плохо для закладки, и т.д.), но либо содержание пути было бы лучше динамически или даже в новом окне, а чем в iframe.
-1 как сказано в другом ответе: «это не является ни хорошим, ни плохим само по себе, но может быть хорошим или плохим на основе поставленной задачи». Кроме того, проблема с кнопкой «назад» и «вперед» не является специфичной для iframe, она также встречается с другим динамическим контентом. – Christophe
Iframes не являются злыми, они просто еще один инструмент, как и все остальное, и для определения их достоинств вы должны определить контекст, в котором они будут использоваться. Google Image Search и несколько других высокопрофильных сайтов используют iframe для ограниченных целей.
В целом я считаю, что они используются для брендинга или для того, чтобы пользователь мог вернуться на сайт, который перенаправляет пользователя за пределы сайта.
Обратите внимание, что если вы используете кросс-доменные iframe, например. iframe, который ссылается на домен вне того, где страница обслуживается, вы ограничены дизайном по соображениям безопасности и не можете получить через javascript внутренности DOM вне домена, с которым он связан.
Также обратите внимание, что на многих сайтах их сайт не может быть внедрен и будет перекрывать iframe (перенаправление верхнего URL-адреса на их домен).
Re: «вся идея протокола HTTP, что URL всегда будет приводить к уникальному месторасположению»
Я служу всю свою CMS от той же URL для безопасности и масштабируемости (с использованием в основном POST вместо GET параметры). Я не хочу, чтобы безопасный контент отображался без проверки подлинности, а диспетчерская система упрощает разработку, поскольку мне не нужно беспокоиться об аутентификации для каждой новой страницы.
Кроме того, для некоторых приложений SEO не применим (например, для веб-ERP).
Я использую iFrame для обслуживания содержимого из дерева сборки, генерируемого PHP. Я не хочу, чтобы дерево (и видимость узлов) обновлялось всякий раз, когда пользователь хотел просмотреть детали для детали/сборки.
Я рад, что я не один из ваших пользователей! (Невозможно добавить закладку на * all *!) – SamB
Существует несколько usability and accessability issues with iframes. Некоторые браузеры и экранные не могут отображать фреймы, так что вы должны обеспечить альтернативное содержание:
<iframe src="content.html">
<p>
This content will only be displayed by browsers that do not support
iframes. You should provide a link to the content, or in your
case an alternative way to use your widget.
</p>
</iframe>
Если начать обслуживать содержание третьей стороны, вы должны следить за IFRAME захватывая внимание после того, как он закончил загрузку. В то время как небольшое раздражение для обычных пользователей, это может быть очень запутанным для пользователей, просматривающих с помощью прошивок.
Существует значительная проблема с iframe, которая едва ли упоминается, но которая вызывает у меня начинку.
У нашего коллеги есть работа, вложенная в динамически изменяющуюся базу данных, которую мы загрузили в электронные таблицы Google Документов, которые затем показываем на нашем сайте наряду с большим количеством вспомогательных материалов.
Нет абсолютно ничего, что могло бы помешать кому-либо захватить код iframe из моего источника страницы и перетащить его на свою страницу. Теперь они получают все наши данные, обновленные до нескольких минут назад, абсолютно ничего не отображали на их странице.
Если google iframe может быть привязан к определенному домену, это остановит его на своих дорожках.
Любые идеи, яркие искры?
Это довольно старый, но если вы все еще ищете решение, я могу подумать об использовании заголовка «X-Frame-Option», чтобы ограничить, кто может загрузить iframe. Теперь вы не можете явно применить этот заголовок на URL-адресе google, поскольку вы его не контролируете. Но вы можете сделать это, вместо того, чтобы напрямую использовать URL-адрес google docs, придумать свой собственный URL-адрес, который перенаправляет серверную часть на URL-адрес google docs. И тогда вы можете применить соответствующий заголовок «X-Frame-Option» к своему собственному URL-адресу – Suhas
I +1 здесь - единственное предостережение, конечно же, заключается в том, чтобы убедиться, что он действительно идеален (т. Е. Вместо того, чтобы просто использовать Ajax для сбора необходимых данных - сервер всегда может захватывать и анализировать контент сторонних разработчиков «и извлекаться через вызовы вне диапазона). –