Відповіді:
Як і у всіх технологій, у неї є свої злети і падіння. Якщо ви використовуєте iframe, щоб обійти правильно розроблений сайт, то, звичайно, це погана практика. Однак іноді прийнята рамка iframe.
Одна з головних проблем із рамкою iframe пов’язана із закладками та навігацією. Якщо ви використовуєте його, щоб просто вставити сторінку у свій вміст, я вважаю, що це нормально. Саме для цього і є рамка.
Однак я бачив, як також зловживають рамки кадрів. Він ніколи не повинен використовуватися як невід'ємна частина вашого сайту, а як частина вмісту на сайті.
Зазвичай, якщо ви можете зробити це без рамки, це кращий варіант. Я впевнений, що інші можуть мати більше інформації або конкретніші приклади, все це зводиться до проблеми, яку ви намагаєтеся вирішити.
Зважаючи на це, якщо ви обмежені HTML і не маєте доступу до бекенда, наприклад PHP або ASP.NET тощо, іноді кадр є єдиним варіантом.
window.postMessage(), наприклад, для здійснення спільної автоматичної зміни розміру iframe.
Вони не погані практики, вони просто ще один інструмент і вони додають гнучкості.
Для використання в якості стандартного елемента сторінки ... вони хороші, оскільки це простий і надійний спосіб розділити вміст на кілька сторінок. Особливо для створеного користувачем вмісту може бути корисним, щоб «пісочниця» внутрішніх сторінок iframeнастільки погана розмітка не впливала на головну сторінку. Мінус полягає в тому, що якщо ви введете кілька шарів прокрутки (один для браузера, другий для iframe), ваші користувачі зірвуться. Як сказав adzm, ви не хочете використовувати iframeдля первинної навігації, але думайте про них як про текст / розмітку, еквівалентну тому, як було б вставлено відео чи інший медіа-файл.
Для сценаріїв фонових подій вибір, як правило, між прихованим iframeта XmlHttpRequestзавантаженням вмісту для поточної сторінки. Різниця полягає в тому, що iframeгенерує завантаження сторінки, тому ви можете переміщатися назад та вперед у кеш-пам’яті браузера у більшості браузерів. Зауважте, що Google, який використовує XmlHttpRequestвсюди, також використовує iframes у певних випадках, щоб дозволити користувачеві рухатися назад та вперед в історії браузера.
Це "погана практика" використовувати їх, не розуміючи їх недоліків. Повідомлення Adzm дуже їх підсумовує.
З іншого боку, gmail використовує iFrames у фоновому режимі для деяких його більш крутих функцій (наприклад, автоматичне завантаження файлів). Якщо ви знаєте про обмеження iFrames, я не вірю, що ви повинні відчувати будь-які зв'язки щодо їх використання.
Працюючи з ними за багатьох обставин, я дійсно прийшов до думки, що iframe - це еквівалент веб-програмування goto-оператора. Тобто чогось взагалі слід уникати. На сайті вони можуть бути корисними. Однак, крос-сайти, вони майже завжди є поганою ідеєю для будь-якого, крім найпростішого змісту.
Розглянемо можливості ... якщо вони використовуються для параметризованого вмісту, вони створили інтерфейс. І на професійному веб-сайті цей інтерфейс вимагає управління умовами домовленості та версіями, які майже завжди ігноруються, щоб поспішати в Інтернеті.
Якщо використовується для активного вмісту - фреймів, що розміщують скрипт, - існують (різні) міждоменні сценарії обмежень. Деякі можна зламати, але рідко послідовно. І якщо ваш вміст в обрамленні потребує інтерактивності, він буде намагатися це робити поза рамками.
Якщо використовується з ліцензованим контентом, то сайти-учасники обтяжені необхідністю переміщення інформації про права поза межами діапазону між хостами.
Тож, хоча вони є корисними для веб-сайту, вони не підходять для розміщення. Ви набагато краще дивитесь на справжні портали та портлети. Гірше, що вони є улюбленицею кожного веб-аматора - багато технічних менеджерів розглядали їх як рішення багатьох проблем. Насправді вони створюють більше.
Виходячи з мого досвіду, позитивна сторона iframe полягає у виклику сторонніх кодів, що може включати виклик javascript, який викликає a, має Document.write();команду. Як ви можете знати, ці команди не можуть бути викликані асинхронно через те, як вони розбираються (DOM Parser тощо). Прикладом цього є http://sourceforge.net/projects/phpadsnew/ Я скористався iframes, щоб допомогти пришвидшити наш сайт, оскільки було багато дзвінків до phpadsnews, і сайт чекав відповіді, перш ніж приступити до надання різних частини сторінки. за допомогою iframe я зміг дозволити сайту Document.write()рендерувати інші частини сторінки і все ще викликати команду phpads асинхронно. Запобігання та блокування js.
Однозначно використовує для людей, що грають у рамки. Як би ви ще розмістили віджет погодних мереж на своїй сторінці? Єдиний інший спосіб - схопити їх XML і проаналізувати його, але тоді, звичайно, потрібні умови, щоб підкинути графіку погоди постійної погоди ... насправді не варто, але спосіб очищення, якщо у вас є час.
Оригінальна модель кадру (Frameset та Frame-елементи) була дуже поганою з точки зору зручності використання. IFrame vas - пізніший винахід, який не мав стільки проблем, як оригінальна модель набору кадрів, але у нього є його недолік.
Якщо ви дозволите користувачеві переходити всередину IFrame, посилання та закладки не працюватимуть, як очікувалося (тому що ви додаєте до закладок URL-адресу зовнішньої сторінки, але не URL-адресу iframe).
Коли ваша головна сторінка завантажується в протокол HTTP, а частини вашої сторінки потрібно працювати в протоколі HTTPS, iFrame може бити jsonp руками вниз.
Тим більше, якщо ваш тип даних не є json, який потрібно перевести на сервер у json та перекласти на клієнт, наприклад, у складний html.
Так що ні - iFrame не є злим.
Вони не погані, але насправді корисні. Деякий час тому у мене була величезна проблема, коли мені довелося вставляти свій канал Twitter, і він просто не дозволяв md робити це на одній сторінці, тому я встановив його на іншій сторінці і поставив її як іфрамеру.
Вони також хороші тим, що всі браузери (і браузери телефону) підтримують їх. Вони не можна вважати поганою практикою, якщо ви правильно їх використовуєте.
Варто відзначити, що iframes, незалежно від швидкості підключення до Інтернету ваших користувачів або вмісту iframe, спричинить невелике (0,3 секунди або близько), але помітне уповільнення швидкості завантаження вашої сторінки. Це не те, що ви побачите під час тестування локально. Насправді це стосується будь-якого елемента, доданого на сторінку, але рамки здаються гіршими.
Я бачив, що IFRAME дуже успішно застосовуються як простий спосіб створення динамічних контекстних меню, але цільовою аудиторією цього веб-додатка були лише користувачі Internet Explorer.
Я б сказав, що все залежить від ваших вимог. Якщо ви хочете переконатися, що ваша сторінка працює однаково добре у кожному веб-переглядачі, уникайте IFRAME. Якщо ви орієнтовані на вузьку і добре відому аудиторію (наприклад, в локальній інтранеті) і бачите користь у використанні IFRAME, то я б сказав, що це нормально.