iframes считают 'плохой практикой'? [закрытый]
Посмотрите на эти функции:
$.ajax({
url:'CSS URL HERE',
type:'HEAD',
error: function()
{
AddLocalCss();
},
success: function()
{
//file exists
}
});
И вот ванильная версия JavaScript:
function UrlExists(url)
{
var http = new XMLHttpRequest();
http.open('HEAD', url, false);
http.send();
return http.status!=404;
}
if (!UrlExists('CSS URL HERE') {
AddLocalCss();
}
Теперь фактическая функция:
function AddLocalCss(){
document.write('')
}
Просто убедитесь, что в голову вызывается AddLocalCss.
Вы также можете рассмотреть один из следующих способов , объясненных в этом ответе :
Загрузка с использованием AJAX
$.get(myStylesLocation, function(css)
{
$('')
.html(css)
.appendTo("head");
});
Загрузка с использованием динамически созданного
$('')
.appendTo("head");
Load using dynamically-created ')
.html('@import url("' + myStylesLocation + '")')
.appendTo("head");
или
$('')
.appendTo("head");
8 ответов
Как со всеми технологиями, это имеет свои взлеты и падения. Если Вы используете iframe для обхождения правильно разработанного сайта, то, конечно, это - плохая практика. Однако иногда iframe приемлем.
Одна из основных проблем с iframe имеет отношение к закладкам и навигации. Если Вы используете его для простого встраивания страницы в содержании, я думаю, что это прекрасно. Именно это iframe для.
Однако я видел iframes, злоупотребленный также. Это никогда не должно использоваться в качестве неотъемлемой части Вашего сайта, но как часть содержания на сайте.
Обычно, если можно сделать это без iframe, который является более оптимальным вариантом. Я уверен, что у других здесь может быть больше информации или более определенных примеров, все это сводится к проблеме, которую Вы пытаетесь решить.
После этих слов если Вы ограничены HTML и не имеете никакого доступа к бэкенду как PHP или ASP.NET и т.д., иногда iframe является Вашей единственной опцией.
Это - 'плохая практика' для использования их, не понимая их недостатков. Сообщение Adzm подводит итог их очень хорошо.
На обратной стороне, Gmail делает интенсивное использование iFrames в фоновом режиме для части, он - более прохладные функции (как автоматическая загрузка файла). Если Вы знаете об ограничениях iFrames, я не полагаю, что необходимо чувствовать любое раскаяние об использовании их.
Они не плохая практика, они - просто другой инструмент, и они добавляют гибкость.
Для использования в качестве стандартного элемента страницы... они хороши, потому что они - простой и надежный способ разделить содержание на несколько страниц. Специально для пользовательского контента может быть полезно "поиграть в песочнице" внутренние страницы в iframe, таким образом, плохая разметка не влияет на основную страницу. Оборотная сторона - то, что, если Вы представляете несколько слоев прокрутки (один для браузера, один для iframe) Ваши пользователи будут расстроены. Как сказанный adzm, Вы не хотите использовать iframe для основной навигации, но думать о них как текст/разметка, эквивалентный способу, которым были бы встроены видео или другой медиа-файл.
Для сценариев фоновых событий, выбор обычно между скрытым iframe и XmlHttpRequest для загрузки содержания для текущей страницы. Различие там - то, что iframe генерирует загрузку страницы, таким образом, можно попятиться и передать в кэше браузера с большинством браузеров. Заметьте, что Google, кто использует XmlHttpRequest повсеместно, также использует iframe с в определенных случаях, чтобы позволить пользователю пятиться и передавать в истории браузера.
Стоит отметить, что iframes будет, независимо от скорости интернет-соединения Ваших пользователей или содержания iframe, вызвать маленькое (приблизительно 0.3 с), но значимое замедление в скорости Ваши загрузки страницы. Это не что-то, что Вы будете видеть при тестировании его локально. На самом деле это верно для любого элемента, добавленного к странице, но iframes, кажется, хуже.
Я видел IFRAMEs, примененный очень успешно как простой способ сделать динамические контекстные меню, но целевая аудитория того веб-приложения была только пользователями Internet Explorer.
я сказал бы, что все это зависит от Ваших требований. Если Вы хотите удостовериться, что Ваша страница работает одинаково хорошо над каждым браузером, избегайте IFRAMEs. При предназначении для узкой и известной аудитории (например, на локальной Интранет), и Вы видите преимущество в использовании IFRAMEs тогда, я сказал бы, что нормально делать так.
Исходная frameset модель (Frameset и Frame-elements) была очень плоха с точки зрения удобства использования. Сосуд IFrame более позднее изобретение, которое не имело стольких же проблем сколько исходная frameset модель, но она действительно имеет свой недостаток.
, Если Вы позволяете пользователю перейти в IFrame, затем связывается, и закладки не будут работать как ожидалось (потому что Вы отмечаете URL внешней страницы, но не URL iframe).
Поработав с ними во многих обстоятельствах, я действительно пришел к выводу, что iframe являются эквивалентом оператора goto для веб-программирования. То есть чего-то, чего обычно следует избегать. На сайте они могут быть в некоторой степени полезными. Однако межсайтовый, они почти всегда плохая идея для чего-либо, кроме самого простого контента.
Рассмотрите возможности ... если они используются для параметризованного контента, они создали интерфейс. А на профессиональном сайте этот интерфейс требует SLA и управления версиями, которые почти всегда игнорируются в спешке с выходом в Интернет.
Если используется для активного содержимого - фреймов, на которых размещен сценарий - существуют (другие) ограничения для междоменных сценариев. Некоторые из них можно взломать, но редко. И если ваш контент во фрейме должен быть интерактивным, ему будет сложно сделать это за фреймом.
При использовании с лицензионным контентом участвующие сайты обременены необходимостью перемещать информацию о правах вне полосы между хостами.
Таким образом, хотя иногда они полезны на сайте, они не подходят для гибридных приложений. Вам гораздо лучше смотреть на настоящие порталы и портлеты. Что еще хуже, они являются любимцем каждого веб-любителя - многие технические менеджеры используют их как решение многих проблем. На самом деле они создают больше.
Определенно есть применения для людей с iframe. Как еще бы вы разместили виджет погодных сетей на своей странице? Единственный другой способ - получить их XML и проанализировать его, но тогда, конечно, вам понадобятся условия, чтобы подбросить подходящую графику погоды ... не совсем того, но намного чище, если у вас есть время.