302

どこかで、iframe を使用することは「悪い習慣」であるという考えに気づきました。

これは本当ですか？それらを使用することの長所/短所は何ですか?

4

11 に答える 11

235

すべてのテクノロジーと同様に、浮き沈みがあります。適切に開発されたサイトを回避するために iframe を使用している場合、もちろんそれは悪い習慣です。ただし、iframe が許容される場合もあります。

iframe の主な問題の 1 つは、ブックマークとナビゲーションに関係しています。単にコンテンツ内にページを埋め込むために使用しているのであれば、それで問題ないと思います。それがiframeの目的です。

ただし、iframe も悪用されているのを見てきました。サイトの不可欠な部分としてではなく、サイト内のコンテンツの一部として使用する必要があります。

通常、iframe なしで実行できる場合は、それがより適切なオプションです。ここにいる他の人には、より多くの情報やより具体的な例があると思いますが、それはすべて、解決しようとしている問題に帰着します。

そうは言っても、HTML に制限されていて、PHP や ASP.NET などのバックエンドにアクセスできない場合は、iframe が唯一の選択肢になることがあります。

于 2008-12-12T13:36:58.513 に答える
81

それらは悪い習慣ではなく、単なる別のツールであり、柔軟性を追加します。

標準のページ要素として使用するには... コンテンツを複数のページに分割するためのシンプルで信頼性の高い方法であるため、優れています。特にユーザー生成コンテンツの場合、内部ページを "サンドボックス" にしてiframe、不適切なマークアップがメイン ページに影響を与えないようにすることが役立つ場合があります。欠点は、スクロールの複数のレイヤー (ブラウザ用に 1 つ、.NET 用に 1 つiframe) を導入すると、ユーザーがイライラすることです。adzm が言ったように、主要なナビゲーションに を使用したくないのですがiframe、動画や別のメディア ファイルを埋め込む方法と同等のテキスト/マークアップと考えてください。

バックグラウンド イベントをスクリプト化する場合、通常は、非表示iframeにするかXmlHttpRequest、現在のページのコンテンツを読み込むかを選択します。違いはiframe、ページの読み込みが生成されるため、ほとんどのブラウザーでブラウザー キャッシュ内を前後に移動できることです。XmlHttpRequestさまざまな場所でsを使用している Googleもiframe、特定のケースでは s を使用して、ユーザーがブラウザーの履歴を前後に移動できるようにしていることに注意してください。

于 2008-12-12T13:41:26.757 に答える
31

それらの欠点を理解せずにそれらを使用するのは「悪い習慣」です。Adzm の投稿は、それらを非常にうまくまとめています。

反対に、gmail はいくつかの優れた機能 (ファイルの自動アップロードなど) のために、バックグラウンドで iFrame を多用します。iFrame の制限を認識しているのであれば、iFrame を使用することに何の不満も感じるべきではないと思います。

于 2008-12-12T13:47:11.130 に答える
19

多くの状況で彼らと仕事をしてきた私は、iframe は goto ステートメントに相当する Web プログラミングであると本当に考えるようになりました。つまり、一般的に避けるべきものです。サイト内では、ある程度役立つ場合があります。ただし、クロスサイトは、ほとんどの場合、最も単純なコンテンツ以外では悪い考えです.

可能性を検討してください...パラメーター化されたコンテンツに使用される場合、それらはインターフェースを作成しました。また、プロのサイトでは、そのインターフェイスには SLA とバージョン管理が必要ですが、ほとんどの場合、急いでオンラインにすると無視されます。

アクティブ コンテンツ (スクリプトをホストするフレーム) に使用する場合、(異なる) クロス ドメイン スクリプトの制限があります。一部はハッキングされる可能性がありますが、一貫してハッキングされることはめったにありません。また、フレーム化されたコンテンツがインタラクティブである必要がある場合、フレームを超えてそうするのは困難です。

ライセンスされたコンテンツで使用する場合、参加サイトは、資格情報をホスト間の帯域外に移動する必要があるため、負担がかかります。

そのため、サイト内で役立つこともありますが、マッシュアップにはあまり適していません。実際のポータルとポートレットを見た方がはるかに優れています。さらに悪いことに、彼らはすべての Web アマチュアの寵児であり、多くの技術マネージャーが多くの問題の解決策として彼らをつかんでいます。実際、彼らはもっと多くのものを生み出しています。

于 2010-01-29T16:41:31.487 に答える
10

私の経験に基づくと、iframe の良い面Document.write();は、サード パーティのコードを呼び出すときです。これには、hasコマンドを呼び出す JavaScript の呼び出しが含まれる場合があります。ご存知かもしれませんが、これらのコマンドは解析方法 (DOM パーサーなど) が原因で、非同期的に呼び出すことができません。この例はhttp://sourceforge.net/projects/phpadsnew/ですページの一部。iframe を使用すると、サイトがページの他の部分をレンダリングできるようにし、Document.write()非同期で phpads のコマンドを呼び出すことができました。防止と js ロック。

于 2013-06-17T06:16:05.430 に答える
8

iframes の人々には間違いなく用途があります。ページに気象ネットワーク ウィジェットを配置するには、他にどのような方法がありますか? 他の唯一の方法は、XML を取得して解析することですが、もちろん、関連する天気図を表示するための条件が必要です... それほど価値はありませんが、時間があればきれいになります。

于 2010-03-03T15:40:23.947 に答える
6

元のフレームセット モデル (Frameset および Frame-elements) は、使いやすさの観点から非常に悪いものでした。IFrame は後の発明で、元のフレームセット モデルほど多くの問題はありませんでしたが、欠点があります。

ユーザーが IFrame 内を移動できるようにすると、リンクとブックマークは期待どおりに機能しません (iframe の URL ではなく、外側のページの URL をブックマークするため)。

于 2008-12-13T14:31:13.413 に答える
5

メイン ページが HTTP プロトコルで読み込まれ、ページの一部が HTTPS プロトコルで動作する必要がある場合、iFrame は jsonp に勝る可能性があります。

特に、dataType がネイティブの json ではなく、サーバーで json に変換し、クライアントで複雑な html などに変換する必要がある場合。

いいえ、iFrame は悪ではありません。

于 2013-08-05T10:19:14.860 に答える
5

ユーザーのインターネット接続の速度や iframe のコンテンツに関係なく、iframe はわずか (0.3 秒程度) ですが、ページのダウンロード速度が著しく低下することに注意してください。これは、ローカルでテストしたときに表示されるものではありません。実際、これはページに追加されたすべての要素に当てはまりますが、iframe はさらに悪いようです。

于 2008-12-12T13:54:52.363 に答える
4

IFRAME が動的なコンテキスト メニューを作成する簡単な方法として非常にうまく適用されているのを見てきましたが、その Web アプリの対象ユーザーは Internet Explorer ユーザーのみでした。

それはすべてあなたの要件に依存すると思います。ページがすべてのブラウザで同じように機能することを確認したい場合は、IFRAME を避けてください。限定的でよく知られている視聴者 (ローカルのイントラネットなど) を対象としていて、IFRAME を使用するメリットがある場合は、そうしても問題ないと思います。

于 2008-12-12T13:43:21.420 に答える