Где-то вдоль линии я понял, что использование iframes - "плохая практика".
Это правда? Каковы плюсы и минусы их использования?
Где-то вдоль линии я понял, что использование iframes - "плохая практика".
Это правда? Каковы плюсы и минусы их использования?
Как и во всех технологиях, он имеет свои взлеты и падения. Если вы используете iframe, чтобы обойти правильно разработанный сайт, то, конечно, это плохая практика. Однако иногда iframe является приемлемым.
Одна из основных проблем с iframe связана с закладками и навигацией. Если вы используете его для простого встраивания страницы в свой контент, я думаю, что все в порядке. Для этого необходим iframe.
Однако я видел, как iframe злоупотребляли. Он никогда не должен использоваться как неотъемлемая часть вашего сайта, а как часть контента на сайте.
Обычно, если вы можете сделать это без iframe, это лучший вариант. Я уверен, что у других здесь может быть больше информации или более конкретных примеров, все сводится к проблеме, которую вы пытаетесь решить.
С учетом сказанного, если вы ограничены HTML и не имеете доступа к бэкэнд как PHP или ASP.NET и т.д., иногда iframe является вашим единственным вариантом.
Это не плохая практика, они просто еще один инструмент, и они добавляют гибкость.
Для использования в качестве элемента стандартной страницы... они хороши, потому что это простой и надежный способ разделить контент на несколько страниц. Специально для пользовательского контента может быть полезно, чтобы внутренние страницы "песочницы" были в iframe
, поэтому плохая разметка не влияет на основную страницу. Недостатком является то, что если вы вводите несколько слоев прокрутки (один для браузера, один для iframe
), ваши пользователи будут разочарованы. Как и в adzm, вы не хотите использовать iframe
для основной навигации, но думайте о них как о тексте/разметке, эквивалентном тому, как будет вложено видео или другой файл мультимедиа.
Для сценариев фоновых событий выбор обычно находится между скрытыми iframe
и XmlHttpRequest
для загрузки содержимого для текущей страницы. Разница в том, что iframe
создает загрузку страницы, поэтому вы можете перемещаться назад и вперед в кеше браузера с большинством браузеров. Обратите внимание, что Google, который использует XmlHttpRequest
повсюду, также использует iframe
в определенных случаях, чтобы позволить пользователю перемещаться назад и вперед в истории браузера.
Это "плохая практика", чтобы использовать их, не понимая их недостатков. Adzm post суммирует их очень хорошо.
На обратной стороне gmail сильно использует iFrames в фоновом режиме для некоторых из них более холодных функций (например, для автоматической загрузки файлов). Если вы знаете об ограничениях iFrames, я не считаю, что вы должны испытывать какие-либо затруднения в их использовании.
Работая с ними во многих случаях, я действительно думал, что iframe - это эквивалент веб-программирования инструкции goto. То есть чего-то вообще можно избежать. Внутри сайта они могут быть несколько полезными. Однако, кросс-сайт, они почти всегда являются плохими идеями для чего угодно, кроме самого простого контента.
Рассмотрим возможности... если они используются для параметризованного контента, они создали интерфейс. И на профессиональном сайте для этого интерфейса требуется SLA и управление версиями, которые почти всегда игнорируются в спешке, чтобы подключиться к сети.
Если используется для активного содержимого - фреймы с хостом script - тогда существуют (разные) кросс-доменные ограничения script. Некоторые могут быть взломаны, но редко последовательно. И если ваш обрамленный контент должен быть интерактивным, он будет не в состоянии сделать это за рамками.
Если используется с лицензированным контентом, то участвующие сайты обременены необходимостью пересылать информацию о правах вне зоны между хостами.
Таким образом, хотя они иногда полезны внутри сайта, они скорее не подходят для mashup. Вы гораздо лучше смотрите на настоящие порталы и портлеты. Хуже того, они любят каждого любителя веб-сайтов - многие технические руководители навязывают им решение многих проблем. Фактически, они создают больше.
Основываясь на моем опыте, положительная сторона для iframe - это при вызове кодов сторонних производителей, которые могут включать вызов javascript, который вызывает a, имеет команду Document.write();
. Как вы знаете, эти команды не могут быть вызваны асинхронно из-за того, как они анализируются (DOM Parser и т.д.). Примером этого является http://sourceforge.net/projects/phpadsnew/. Я использовал iframes, чтобы ускорить наш сайт, так как было несколько вызовов phpadsnews и сайта ожидал ответа, прежде чем приступить к визуализации различных частей страницы. с iframe я смог разрешить сайту отображать другие части страницы и по-прежнему вызывать команду Document.write()
phpads асинхронно. Предотвращение и блокировка js.
Определенно используются для пользователей iframes. Как еще вы поместили бы виджет погодных сетей на свою страницу? Единственный другой способ - захватить их XML и проанализировать его, но тогда, конечно, вам нужны условия, чтобы вытащить вечную графику погоды... на самом деле это не стоит, но, если у вас есть время, более чистым.
Оригинальная модель фреймов (Frameset и Frame-elements) была очень плохой с точки зрения удобства использования. IFrame - это более позднее изобретение, в котором не было столько проблем, как исходная модель набора фреймов, но у него есть свой недостаток.
Если вы разрешаете пользователю перемещаться внутри IFrame, ссылки и закладки не будут работать должным образом (поскольку вы закладите URL-адрес внешней страницы, но не URL-адрес iframe).
Я видел, что IFRAME применялись очень успешно, как простой способ создания динамических контекстных меню, но целевая аудитория этого веб-приложения была только пользователями Internet Explorer.
Я бы сказал, что все зависит от ваших требований. Если вы хотите, чтобы ваша страница работала одинаково хорошо в каждом браузере, избегайте использования IFRAME. Если вы ориентируетесь на узкую и известную аудиторию (например, на локальную интрасеть), и вы видите преимущество использования IFRAME, я бы сказал, что это нормально.
Стоит отметить, что iframe будет, независимо от скорости подключения к Интернету вашего пользователя или содержимого iframe, вызывать небольшое (0,3 или около того), но заметное замедление скорости загрузки вашей страницы. Это не то, что вы увидите при локальном тестировании. На самом деле, это верно для любого элемента, добавленного на страницу, но iframes кажется хуже.
Когда ваша основная страница загружается в HTTP-протоколе, а части вашей страницы должны работать в протоколе HTTPS, iFrame может превзойти руки jsonp.
В частности, если ваш dataType не является изначально json и должен быть переведен на сервер в json и переведен на клиент обратно, например. сложный html.
Так что nope - iFrame не злой.
Они неплохие, но на самом деле полезные. Некоторое время назад у меня была огромная проблема, когда мне пришлось встроить свой твиттер-канал, и он просто не позволил бы md сделать это на одной странице, поэтому я установил его на другую страницу и поместил в него как iframe.
Они также хороши, потому что все браузеры (и телефонные браузеры) поддерживают их. Они не могут считаться плохой практикой, если вы используете их правильно.