Считаются ли фреймы "плохой практикой"?
Ответы 11
Как и у всех технологий, у него есть свои взлеты и падения. Если вы используете iframe для обхода правильно разработанного сайта, то, конечно, это плохая практика. Однако иногда допускается использование iframe.
Одна из основных проблем iframe связана с закладками и навигацией. Если вы используете его, чтобы просто встроить страницу в свой контент, я думаю, что это нормально. Вот для чего нужен iframe.
Однако я также видел злоупотребление iframe. Его никогда не следует использовать как неотъемлемую часть вашего сайта, а только как часть контента на сайте.
Обычно, если вы можете сделать это без iframe, это лучший вариант. Я уверен, что у других здесь может быть дополнительная информация или более конкретные примеры, все сводится к проблеме, которую вы пытаетесь решить.
С учетом сказанного, если вы ограничены HTML и не имеете доступа к серверной части, такой как PHP или ASP.NET и т. д., Иногда iframe - ваш единственный вариант.
@ developer747 - это не сработает, если внешний контент находится на другом сайте из-за та же политика происхождения. В некоторых непонятных случаях удаленный сайт может поддерживать JSONP; но, вероятно, нет.
Мне кажется, что iframe намного менее полезны, чем предыдущий набор фреймов, потому что размер iframe не может быть изменен пользователем, но я бы не использовал набор фреймов для чего-либо, кроме руководства, поскольку его больше нет в html5. Пример: Руководство по созданию игр
Следует отметить, что в настоящее время iframe - единственный способ определить вложенную область CSS. Они изолируют внутреннюю разметку, макет, стиль и Javascript * от внешнего документа, что полезно во многих случаях использования и приложений. * Javascript не изолирован, если внутренний документ имеет одно и то же происхождение с внешним; с другой стороны, документы из разных источников могут по-прежнему обмениваться данными с помощью window.postMessage(), например, для реализации совместного автоматического изменения размера iframe.
Нет. Это плохая практика. Они препятствуют доступности и автоматическому тестированию, а значит, и масштабируемости.
Это инструмент, НЕТ инструмента - ПЛОХАЯ практика, плохим может быть только код разработчика. Они, как и любой другой тег, при практическом использовании бесценны в веб-разработке. они позволяют вставлять один документ в другой, как правило, из разделенной системы. Как и все теги, погуглите и прочтите о некоторых плохих внедрениях, но у правильной реализации нет недостатков. Запретить доступность - это полная и сплошная чушь. Я использовал фреймы для создания сайтов для слепых, и они прекрасно их читают ... #caseclosed
Тобия здесь абсолютно прав. В настоящее время я работаю над некоторым веб-приложением, которое требует изоляции CSS. Если вы знакомы с Bower, он упаковывает весь ваш CSS в один файл; если вы вызываете что-то, что динамически создает некоторый CSS на странице с помощью этого файла main.css, это может вызвать конфликт. Таким образом, iframe отлично подходит для разделения этих двух элементов, и я считаю, что это довольно хорошее его использование.
Это неплохая практика, это просто еще один инструмент, который добавляет гибкости.
Для использования в качестве стандартного элемента страницы ... они хороши, потому что это простой и надежный способ разделить контент на несколько страниц. Специально для пользовательского контента может быть полезно поместить внутренние страницы в «песочницу» в iframe, чтобы плохая разметка не повлияла на главную страницу. Обратной стороной является то, что если вы введете несколько уровней прокрутки (один для браузера, один для iframe), ваши пользователи будут разочарованы. Как сказал adzm, вы не хотите использовать iframe для первичной навигации, но думайте о них как о тексте / разметке, эквивалентном способу встраивания видео или другого мультимедийного файла.
Для сценариев фоновых событий обычно выбирают между скрытым iframe и XmlHttpRequest для загрузки содержимого для текущей страницы. Разница в том, что iframe генерирует загрузку страницы, поэтому вы можете перемещаться вперед и назад в кеше браузера с большинством браузеров. Обратите внимание, что Google, который повсеместно использует XmlHttpRequest, в некоторых случаях также использует iframe, чтобы позволить пользователю перемещаться вперед и назад в истории браузера.
Думаю, важно упомянуть, что фреймы можно использовать для встраивания страницы из одного домена в страницу из другого домена. Если встроенная страница хочет отслеживать пользователей с помощью файлов cookie и хранить эту информацию из домена хоста, то единственный вариант - использовать iframe, поскольку JS находится под контролем домена хоста.
@NicholasLeonard Хорошим примером является то, что вы можете использовать их для принудительного кэширования страницы на основе локального хранилища, сделав страницу индекса скриптом, который определяет, находится ли подстраница в локальном хранилище. Затем, document.write его из localstorage, если он там, а если нет, добавьте iframe на эту подстраницу. На этой подстранице есть сценарий для хранения внешнего HTML-элемента подстраницы в localstorage. ДЕЙСТВИТЕЛЬНО веская причина использовать этот метод заключается в том, что он позволяет вам добавить экран загрузки.
Я не согласен, но Я не могу проголосовать против, потому что это важная точка зрения.
Я видел, как IFRAME применяются очень успешно как простой способ создания динамических контекстных меню, но целевой аудиторией этого веб-приложения были только пользователи Internet Explorer.
Я бы сказал, что все зависит от ваших требований. Если вы хотите, чтобы ваша страница одинаково хорошо работала во всех браузерах, избегайте IFRAME. Если вы ориентируетесь на узкую и хорошо известную аудиторию (например, в местной интрасети) и видите преимущества использования IFRAME, то я бы сказал, что это нормально.
«Плохая практика» - использовать их, не понимая их недостатков. Сообщение Адзма очень хорошо их подводит.
С другой стороны, Gmail интенсивно использует iFrames в фоновом режиме для некоторых своих более крутых функций (например, автоматической загрузки файлов). Если вы знаете об ограничениях iFrames, я не думаю, что вы должны испытывать какое-либо сожаление по поводу их использования.
Стоит отметить, что iframe будет, независимо от скорости интернет-соединения ваших пользователей или содержимого iframe, вызывать небольшое (0,3 с или около того), но заметное замедление скорости загрузки вашей страницы. Это не то, что вы увидите при локальном тестировании. Собственно, это верно для любого элемента, добавляемого на страницу, но фреймы кажутся хуже.
Почему? И есть ли способ заставить фреймы загружаться после завершения загрузки главной страницы?
Я не помню, почему они такие медленные; Я исследовал это год назад. Вероятно, потому, что браузер в основном создает совершенно новый контекст рендеринга для каждого iframe. Что касается того, чтобы они не загружались до завершения загрузки страницы, вы можете использовать пустой iframe, а затем установить тег src iframe после завершения загрузки страницы. Однако обратите внимание, что даже пустой iframe замедлит рендеринг вашей страницы, но не загрузку, поэтому пользователям все равно будет казаться немного медленнее.
Напротив, можно рассмотреть возможность обсуждения CDN (сетей доставки контента), когда речь идет о скорости и iFrames. Учтите, что iFrame может загружать ресурсы параллельно и, следовательно, обеспечивать повышение скорости (в зависимости от браузера). Вот как минимум еще одна ссылка, которая согласуется с моей позицией. developer.yahoo.com/performance/rules.html
@Strixy: в указанном вами URL указано, что IFrames являются дорогостоящими, даже если они пустые. Он рекомендует свести к минимуму использование IFrames. Использование CDN для ускорения вашего сайта ортогонально использованию IFrames. CDN может помочь снизить стоимость использования IFrame. Однако CDN без IFrame лучше, чем CDN и IFrame.
@Brian Просто думаю вслух и наслаждаюсь дебатами. У меня сложилось впечатление, что это зависит от того, как iFrame используется и с какой целью. Время загрузки рассчитывается на основе времени, необходимого для загрузки контента, а также времени, необходимого для рендеринга. Если вы можете загружать ресурсы параллельно через iFrame, не восполнит ли это некоторую потерю времени на этапе рендеринга этого расчета, но только если размер загружаемых данных превышает время рендеринга? Итак, что это за времена, я полагаю, это будет следующим направлением для дебатов, да?
@Strixy: если вы хотите загружать ресурсы параллельно, есть способы сделать это лучше. Старая популярность - загружать все это через javascript. Новая популярность заключается в использовании Service worker, который эффективно позволяет вам напрямую управлять тем, как пользовательский агент загружает, предварительно загружает и кэширует ресурсы сайта, используя логику на стороне клиента. Другая новинка - это http / 2 push, который позволяет отправлять ресурсы в браузер, не дожидаясь, пока браузер запросит их. Однако, поскольку кеш http / 2 проверяется после других кешей браузера, это часто плохой выбор для этой цели.
@ Брайан В самом деле. За последние 6 лет многое изменилось.
Исходная модель набора фреймов (Frameset и Frame-elements) была очень плохой с точки зрения удобства использования. IFrame был более поздним изобретением, у которого не было столько проблем, как у исходной модели набора фреймов, но у него есть свой недостаток.
Если вы разрешите пользователю перемещаться внутри IFrame, то ссылки и закладки не будут работать должным образом (потому что вы добавляете в закладки URL-адрес внешней страницы, но не URL-адрес iframe).
вынужден не соглашаться ... такой широкий комментарий не имеет смысла.
Поработав с ними во многих обстоятельствах, я действительно пришел к выводу, что iframe являются эквивалентом оператора goto для веб-программирования. То есть чего-то, чего обычно следует избегать. На сайте они могут быть полезны. Однако межсайтовый, они почти всегда плохая идея для чего-либо, кроме самого простого контента.
Рассмотрите возможности ... если они используются для параметризованного контента, они создали интерфейс. А на профессиональном сайте этот интерфейс требует SLA и управления версиями, которые почти всегда игнорируются в спешке с выходом в Интернет.
Если используется для активного контента - фреймов, на которых размещен скрипт, - существуют (другие) ограничения междоменного скрипта. Некоторые из них можно взломать, но редко. И если ваш контент во фрейме должен быть интерактивным, ему будет сложно сделать это за фреймом.
Если они используются с лицензионным контентом, то участвующие сайты обременены необходимостью перемещать информацию о правах вне полосы между хостами.
Таким образом, хотя иногда они полезны на сайте, они не подходят для гибридных приложений. Вам гораздо лучше смотреть на настоящие порталы и портлеты. Что еще хуже, они являются любимцем каждого веб-любителя - многие технические менеджеры используют их как решение многих проблем. На самом деле они создают больше.
Определенно, люди, использующие iframe, находят применение. Как еще вы бы разместили виджет погодных сетей на своей странице? Единственный другой способ - получить их XML и проанализировать его, но тогда, конечно, вам понадобятся условия, чтобы подбросить подходящую графику погоды ... на самом деле это не стоит, но намного чище, если у вас есть время.
Основываясь на моем опыте, Положительная сторона для iframe возникает при вызове сторонних кодов, что может включать вызов javascript, который вызывает команду Document.write();. Как вы, возможно, знаете, эти команды нельзя вызывать асинхронно из-за того, как они анализируются (парсер DOM и т. д.). Примером этого является http://sourceforge.net/projects/phpadsnew/. Я использовал фреймы, чтобы ускорить работу нашего сайта, поскольку было несколько обращений к phpadsnews, и сайт ждал ответа, прежде чем приступить к визуализации различных частей страницы. с помощью iframe я смог разрешить сайту отображать другие части страницы и по-прежнему асинхронно вызывать команду Document.write() phpads. Предотвращение и блокировка js.
Когда ваша главная страница загружается по протоколу HTTP, а части вашей страницы должны работать по протоколу HTTPS, iFrame может легко превзойти jsonp.
Особенно, если ваш dataType изначально не json и должен быть переведен на сервере в json и переведен на клиенте обратно, например, сложный html.
Так что нет - iFrame не зло.
Они неплохие, но действительно полезные. Некоторое время назад у меня была огромная проблема, когда мне пришлось встроить свой канал Twitter, и он просто не позволял md делать это на той же странице, поэтому я установил его на другой странице и вставил как iframe.
Они хороши еще и тем, что их поддерживают все браузеры (и браузеры телефонов). Их нельзя считать плохой практикой, если вы их правильно используете.
«если вы ограничены HTML и не имеете доступа к серверной части, такой как PHP или ASP.NET и т. д., иногда iframe - ваш единственный вариант» ... это не так. Вы можете встроить внешний контент на свою страницу, получив данные через jquery ajax, а затем заполнив div этими данными.