Чому люди все ще використовують фреймрейми? [зачинено]

Для мене іфрейми є чистим злом (ну, можливо, не таким чистим). Здається, вони завдають багато клопоту. Так, весь ваш сайт завантажиться один раз, і тоді ви зможете завантажити лише одну сторінку. Але люди для цього придумали AJAX.

Однією з найбільших проблем, яку я виявив, iframeбуло те, що я не зміг вставити посилання на одну з підсторінок, оскільки URL-адреса ніколи не змінювалася (так, я знаю, що для цього є обхідний шлях). По-друге, веб-пошукові машини можуть мати проблеми з правильним індексуванням цих веб-сайтів.

Іноді доступність цих сайтів гірша, і деякі браузери можуть навіть відображати їх неправильно.

Існують кращі способи проектування макета без (i) рам. Щодня я бачу, як хтось задає запитання SO, наприклад "Як отримати доступ до iframe за допомогою jQuery?".

Отже, які переваги iframes? Яка причина може бути, щоб все-таки ними користуватися? Я просто хотів би знати, чому :)

(оскільки це не справжнє питання, це CW)

Я можу подумати про 2 причини (на даний момент), чому люди все одно використовуватимуть фрейми замість AJAX:

1) Iframes обходять політику міждоменного походження (зображення, сценарії та стилі - ні). Це може бути корисно для відносного безпечного завантаження сайтів / вмісту з інших доменних імен. По суті, це дає перевагу можливості візуально показувати дані з інших доменів, не дозволяючи їм тупотіти по всій вашій сторінці з необмеженим доступом (наприклад, щось на зразок JSONP).

2) Ви можете завантажувати декілька типів ресурсів із внутрішнього кадру, а не лише певні MIME-типи (ви обмежені лише програмами / javascript, application / x-javascript, text / css, text / xml, image / png, image / jpeg, image / gif зі сценаріями, XHR, зображеннями та джерелами). Наприклад, якщо я хочу показати вам PDF, я можу відкрити iframe і дозволити плагіну Adobe Reader показати вам цей файл. Крім того, у тому ж домені, якщо я хочу конвеювати сценарій, стиль та зображення разом (вбудований на сторінці, зображення повинно бути URI даних), я можу виконати це за допомогою iframe (і якщо це в тому ж домену, порту та протоколу, я також можу отримати до нього доступ за допомогою JavaScript).

Чи знали ви, що Gmail - це набір iframes? Видима частина - це просто розумне позиціонування. Крім того, багато реалізацій OAuth (Twitter, Facebook, Google, Yahoo!) зазвичай використовують фрейми, щоб зв’язати користувача у своєму домені з успішною URL-адресою автентифікації (для того, щоб користувач ввійшов у систему).

IFRAME використовуються для вбудовування та ізоляції сторонніх матеріалів на веб-сайті.

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

Іншим сучасним використанням IFRAMES є управління історією (загальний обхідний шлях для повернення кнопки) додатків AJAX.

РАМКИ є поганою версією ІФРАМ. Їх використання зменшується.

Якщо у користувача вимкнено javascript, iframes працюватиме, коли ajax цього не робить. Це не виключено, враховуючи, що люди використовують такі речі, як NoScript .

Я використовую їх на веб-сайтах ajax, коли мені потрібно завантажувати файли без перезавантаження сторінки.

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

Існує безліч технічних причин для їх використання (особливо проблема безпеки, згадана Ден Бімом).

Що не слід робити, це використовувати iframes "як кадри", здійснюючи навігацію до нових сторінок, лише оновлюючи iframe. Як ви говорите, це заважає навігації бути закладкою / посиланням, реагувати на звичайні навігаційні кнопки та надавати корисні можливості для посилань, як відкриття в новій вкладці.

Але це не властиво для фреймів. Ви можете бачити все більше сторінок, на яких здійснюється навігація, отримуючи новий вміст XMLHttpRequestі записуючи його в основні div innerHTML. Часто це робиться за допомогою jQuery load()та розумно-розумних слайд-анімацій. Це порушує навігацію так само погано, як iframe-used-as-frame, або навіть старі шкільні набори кадрів. Шкода, що багато веб-авторів використовують цю тактику, вважаючи, що це суперсучасна методологія веб-дизайну, коли насправді це просто нова шкіра на вчора зневажених наборах кадрів.

Ви можете обійти це в обох випадках, але це означає, що вам потрібно зберегти стан перегляду в #частині ідентифікатора фрагмента та підтримувати належну хеш-навігацію, що не є тривіальним. Навіть тоді у вас все ще виникають проблеми з агентами, що не належать до JS, такими як пошукові системи; у підсумку вам доведеться мати паралельну ?і #засновану навігацію для підтримки обох. Це біль, і більшість не турбує.

Набори фреймів застаріли з HTML 5, і іноді вам потрібно мати фрейм з іншим сайтом на сайті. Також AJAX може зробити лише стільки. Спробуйте завантажити файл на сайт в іншому домені через https без iframe. AJAX не допоможе вам там.

Окрім інших причин, iframeу моїй програмі є одне конкретне використання . На жаль, цільовим браузером у моєму випадку є Internet Explorer 6. Мені потрібно мати нижній колонтитул та заголовок, які зафіксовані на моїх веб-сторінках. Основна частина цієї сторінки є прокручуваною.

Однак у IE6 є помилка, коли я не можу відображати divелемент поверх selectелементів за допомогою z-indexвластивості CSS. Таким чином, мені потрібно створити такий, iframeякий буде використовуватися як хак, щоб уникнути цієї проблеми.

Звичайно, це справді специфічне використання iframeі лише проблема IE6...

Редактори Javascript WYSIWYG використовують фрейми, тому що це найпростіший і найкращий спосіб зробити це. Наприклад, TinyMCE використовує його:

http://tinymce.moxiecode.com/

Я будував соціальну мережу, і я бачу, що фрейми корисні для віджетів, які можна розмістити на веб-сайті інших людей, щоб показати їх як міні-профіль або інтегрувати із вмістом на віддаленому сервері. Здається, це найпростіший спосіб побудувати це. Я знаю, що деякі віджети використовують JavaScript. Також із методом iframe сеанс такий самий, як відвідування сайту як звичайний, настільки чудовий для подібних кнопок.

Багато форматованих текстових редакторів (наприклад, TinyMCE, HTMLArea) реалізовані як iframe.

iFrames - це нормально для деяких випадків, як запити X-домену або розміщення даних у джерелі за допомогою параметрів. Але коли я хочу отримати доступ до даних між доменами, я віддаю перевагу використанню CSS-файлів - вони можуть приймати параметри, встановлювати файли cookie, додавати вміст на сторінку (: до &: після) та давати візуальний зворотний зв'язок.