開発者がiframeを嫌う理由
可能性のある複製：
iframeは「悪い習慣」と見なされていますか？
Web開発者と一緒に作業しているときに、iframeを使用することはできる限り避けなければならないことであり、悪いことや煩わしいこと、そして多くの問題を引き起こすと言う人もいます。
またある日、前のボスに「開発者ではない」とiframeを使用すると言ったとき、彼は私を悪い開発者だと見なしていました:)
私が知りたいのは、iframeにはWeb開発の非常に悪い歴史がありますか？
災害ですか？
場合によっては、iframeを使用する必要があることがわかります。それは、私が悪い開発者であることを意味していますか？
それとも、開発中に注意しなければならないいくつかのセキュリティ問題のために対処するのが難しいため、それらすべてのことですか？
あなたもそれが嫌いならあなたのポイントをリストアップするか、私が間違った方法を考えているなら私を訂正してください。
Iframeには、フレームと同様の問題があり、XMLHttpRequestを不適切に使用する可能性があります。URLごとに1ドキュメントというパラダイムを破ります。これは、Webが適切に機能するために不可欠です（ブックマーク、ディープリンク、検索エンジンなど）。 、...）。
Webアプリケーションを作成している場合は、任意の手法（フレーム、フラッシュ、アプレット、$ whateverなど）を使用します。実際に情報を提供するWebページを作成する場合は、フレームレスHTML、CSS、邪魔にならないJavaScriptを使用し、スクリプトを無効にしてもページは引き続き使用できることに注意してください。
Nosrednaが言ったように、それはおそらく人々がそれらをフレームと混同しているためであり、実際にはフレームに対して多くの有効な議論があります。それらの一部はiframeに適用できませんが、一部は適用されます。
このような問題で最も目立つのは、おそらくディープリンクの問題です。iframeの影響がフレームよりも少ないことは事実ですが、ユーザーがiframe内の異なるページ間を移動できるようにすると、問題が発生します。また、注意が必要なユーザビリティの問題もいくつかあります。最も一般的な例は、私が個人的に信じられないほど迷惑だと思うダブルスクロールバーの問題です。
私はiframeを避けがちですが、それは主にそれが不法な解決策であることがわかったからです。実際に座って考えてみると、ほとんどの場合、より良い解決策があることがわかりました。それにもかかわらず、彼らのための場所があると私はまた信じています。それはウェブの世界の代表です。悪用された歴史があるからといって、決して使用してはならないというコンセンサスになっています。ここでは実際にはそうではありませんが、iframeを使用する前によく考えてください。
私はそれを追加したかったほとんどの場合、iframeはページのSEOにも役立ちません。 Googlebotはiframeのコンテンツをページに配置しません。
Iframeが（ほとんど）必要な状況が1つあります。iframeのコンテンツが別のドメインにあり、そのドメインにバインドされているCookieを確認または確認する必要がある場合です。それは実際にそれらを作成する代わりにセキュリティ問題を防ぎます。
たとえば、任意のWebサイトで使用できる一種のプラグインを作成しているが、プラグインが別のドメインで認証する必要がある場合は、外部ドメインで実行および認証するシームレスなiframeを作成できます。
私は人々がiframeをHTMLフレームと混同していると思います、そしてフレームはかなり普遍的に軽視されています。
人々はそれを実現することさえせずに常にiframeを使用しています。私が正しく思い出せば、TinyMCEはiFrameを使用します。
1つの理由はセキュリティです-iframeインジェクション攻撃はかなり一般的でした。説明については、このArs Technicaページを参照してください。
http://arstechnica.com/security/news/2008/03/ongoing-iframe-attack-proving-difficult-to-kill.ars
いくつかの脆弱性をまとめた別のページ（現在のブラウザーに有効なものの数はわかりませんが、記事はそれほど古いものではありません）：
http://www.thespanner.co.uk/2007/10/24/iframes-security-summary/
一方、これらはクロスドメイン通信を可能にし、「ajaxy」Webアプリケーションで非常に一般的に使用されます。
http://softwareas.com/cross-domain-communication-with-iframes
1つの問題は、独自のページライフサイクルがあるため、ホストとiframeの子の間の対話性が制限されることです（クエリ文字列、セッション変数、またはJS）。別の方法は、スクロールdivの使用を検討することです。
もう1つの問題は印刷です。 iframe（またはその点ではスクロールdiv）の出力は予測できない場合があり、ブラウザーによって大きく異なります。
Webアプリケーションを構築するためのiframeには何の問題もありません。ターゲットコンテンツとメモリカプセル化を組み合わせることができます。誰かが最新のJlibraryを忘れて親ページにアップロードしたり、DIVでロードされたコンテンツをアップロードしたりすると、チャンクを完全に破壊する滑らかな小さなJavaScript Ajaxを何回構築しましたか？他のほとんどの問題はSEOを取り巻くもので、SEOは実際に誰か他の人のコンテンツを盗むことを望んでいる場合にのみ重要です。 iframeを使用すると、メモリをカプセル化し、適切に設計されたページを複数のサイト間で共有できます。多くの人があなたに信じてもらえるとはいえ、Iframeやその同等物は非常に長い間存在します。
私はIFrameが彼らの場所を持っていると思います。 SEOの問題などが原因で、フロントエンド/パブリックWebサイトでは使用しません。内部/バックエンドWebアプリの場合、特定のセクションのスタイリングを分離する必要がある場合に役立つと思いますページの残りの部分から、例えばレポートビューアまたはHTMLエディタ。すべてのコンテンツが1つのドキュメントにある場合、親ページから継承されたスタイルで問題が発生する可能性があります。私の2c ...
拒否される理由の1つは、本質的に遅いためです。 iframeの読み込みが始まるときまでに、ホストページは既に読み込みパイプラインの高度な段階にあります。 iframeとSnappy Browsingを組み合わせることはほとんど不可能です。
今日のiframeは、過去のブラウザーでiframeがサポートされているため、名前が不適切です。 VB6の履歴が原因でラップが不適切なVB.NETに似ています。私は最近、必要に応じてそれらを使用しています...あなたがたまに計画していたようにそれが機能しない可能性があり、それを説明する可能性があることを覚えておいてください。
HTML要素に動作があってはなりません。
Html-describes-contents + css-does-the-visual-designの原理主義全体に反するからだと思います。また、フレームをフェッチするために個別の呼び出しを行うため、iframeの使いすぎはパフォーマンスの無駄になります。考えてみると、AJAXは基本的にiframeのようなものですが、今日の流行ではありません（将来はないかもしれません）。
セキュリティに関しては、ユーザーが知らないうちに他のドメインから合計がらくたをロードできるので、それはちょっと問題があります。
デザインにiframeを使用しないでください。 CSSは同じことをより適切に行い、自由度を大幅に高めます。
それは、セキュリティに関しては扱いが難しいためです。正常に動作する最新のブラウザーでは、ページ上の他のiFrameの要素を操作するコードをiFrameに記述できません。これにより、特定の手法を達成するのが難しい場合があります。