html - Являются ли фреймы «плохой практикой»?





iframe standards (10)


Оригинальная модель фреймов (Frameset и Frame-elements) была очень плохой с точки зрения удобства использования. IFrame - это более позднее изобретение, у которого не было столько проблем, как исходная модель набора фреймов, но у него есть свой недостаток.

Если вы разрешаете пользователю перемещаться внутри IFrame, ссылки и закладки не будут работать должным образом (поскольку вы закладите URL-адрес внешней страницы, но не URL-адрес iframe).

Где-то вдоль линии я понял, что использование iframes - «плохая практика».

Это правда? Каковы плюсы и минусы их использования?




Определенно используются для людей iframes. Как еще вы поместили бы виджет погодных сетей на свою страницу? Единственный другой способ - захватить их XML и проанализировать его, но тогда, конечно, вам нужны условия, чтобы вытащить вечную графику погоды ... на самом деле это не стоит, но, если вы имеете время, более чистым.




Это «плохая практика», чтобы использовать их, не понимая их недостатков. Сообщение Адзма подводит итог.

На обратной стороне gmail сильно использует iFrames в фоновом режиме для некоторых из его более холодных функций (например, для автоматической загрузки файлов). Если вы знаете об ограничениях iFrames, я не верю, что вы должны испытывать какие-либо уговоры об их использовании.




Стоит отметить, что iframe будет, независимо от скорости подключения к Интернету вашего пользователя или содержимого iframe, вызвать небольшое (0,3 или около того), но заметное замедление скорости загрузки вашей страницы. Это не то, что вы увидите при локальном тестировании. На самом деле, это верно для любого элемента, добавленного на страницу, но iframes кажется хуже.




Основываясь на моем опыте, положительная сторона iframe при вызове кодов сторонних производителей, которые могут включать вызов javascript, который вызывает a, имеет Document.write(); команда. Как вы знаете, эти команды не могут быть вызваны асинхронно из-за того, как они анализируются (DOM Parser и т. Д.). Примером этого является http://sourceforge.net/projects/phpadsnew/ Я использовал iframes, чтобы ускорить наш сайт, поскольку было несколько вызовов phpadsnews, и сайт ожидал ответа, прежде чем приступать к части страницы. с iframe я смог разрешить сайту отображать другие части страницы и асинхронно вызывать команду Document.write() phpads. Предотвращение и блокировка js.




Как и во всех технологиях, он имеет свои взлеты и падения. Если вы используете iframe, чтобы обойти правильно разработанный сайт, то, конечно, это плохая практика. Однако иногда iframe является приемлемым.

Одна из основных проблем с iframe связана с закладками и навигацией. Если вы используете его для простого встраивания страницы в свой контент, я думаю, что все в порядке. Для этого необходим iframe.

Однако я видел, как iframe злоупотребляли. Он никогда не должен использоваться как неотъемлемая часть вашего сайта, а как часть контента внутри сайта.

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

С учетом сказанного, если вы ограничены HTML и не имеете доступа к бэкэнд как PHP или ASP.NET и т. Д., Иногда iframe является вашим единственным вариантом.




Они неплохие, но на самом деле полезны. Некоторое время назад у меня была огромная проблема, когда мне нужно было вставлять свой канал Twitter, и это просто не позволит md делать это на одной странице, поэтому я установил его на другую страницу и поместил его как iframe.

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




Работая с ними во многих случаях, я действительно думал, что iframe - это эквивалент веб-программирования инструкции goto. То есть чего-то вообще можно избежать. Внутри сайта они могут быть несколько полезными. Однако, кросс-сайт, они почти всегда плохая идея для чего угодно, кроме самого простого контента.

Рассмотрите возможности ... если они используются для параметризованного контента, они создали интерфейс. И на профессиональном сайте для этого интерфейса требуется SLA и управление версиями, которые почти всегда игнорируются в спешке, чтобы выйти в интернет.

Если используется для активного содержимого - кадры, которые содержат сценарий хоста, то существуют (разные) ограничения скрипта междоменного домена. Некоторые могут быть взломаны, но редко последовательно. И если ваш обрамленный контент должен быть интерактивным, он будет изо всех сил стараться делать это за рамками.

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

Таким образом, хотя они иногда полезны на сайте, они скорее не подходят для mashup. Вы гораздо лучше смотрите на настоящие порталы и портлеты. Хуже того, они любят каждого любителя веб-сайтов - многие технические руководители навязывают им решение многих проблем. Фактически, они создают больше.




Я видел, как IFRAME применялись очень успешно, как простой способ создания динамических контекстных меню, но целевая аудитория этого веб-приложения была только пользователями Internet Explorer.

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




Если <iframe> принадлежит к одному домену, элементы легко доступны как

$("#iFrame").contents().find("#someDiv").removeClass("hidden");

Reference







html iframe standards