iframeは「悪い習慣」と見なされていますか？[閉まっている]

どこかで、iframeを使用することは「悪い習慣」であるという概念を取り上げました。

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

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

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

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

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

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

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

標準のページ要素として使用する場合...コンテンツは複数のページに分割するシンプルで信頼性の高い方法であるため、優れています。特にユーザーが作成したコンテンツの場合は、内部ページを「サンドボックス化」して、iframeマークアップが不十分であってもメインページに影響が及ばないようにすると便利です。欠点は、スクロールの複数のレイヤー（1つはブラウザー用、もう1つはiframe）を導入すると、ユーザーが不満を感じるようになることです。adzmが言ったように、iframeプライマリナビゲーションにを使用したくないが、それらをビデオまたは別のメディアファイルを埋め込む方法と同等のテキスト/マークアップと考えてください。

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

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

逆に、GmailはバックグラウンドでiFrameを頻繁に使用して、一部の優れた機能（自動ファイルアップロードなど）を実現しています。iFrameの制限を認識している場合は、iFrameの使用について何の責任も感じないはずです。

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

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

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

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

そのため、サイト内ではたまに役立つものの、マッシュアップにはあまり適していません。実際のポータルとポートレットをはるかによく見ることができます。さらに悪いことに、それらはすべてのウェブアマチュアの最愛の人です-多くの技術マネージャーが多くの問題の解決策として彼らに圧倒しています。実際には、彼らはより多くを作成します。

私の経験に基づくと、iframeの良い面は、サードパーティのコードを呼び出すときDocument.write();です。ご存知かもしれませんが、これらのコマンドは、解析方法（DOMパーサーなど）が原因で非同期に呼び出すことができません。この例はhttp://sourceforge.net/projects/phpadsnew/です。phpadsnewsへの複数の呼び出しがあり、サイトが応答を待ってから別のレンダリングに進むため、iframeを使用してサイトの高速化を支援しましたページの一部。iframeを使用すると、サイトがページの他の部分をレンダリングしDocument.write()、phpads のコマンドを非同期で呼び出すことができるようになりました。防止とjsロック。

確かにiframesの人には用途があります。ページに気象ネットワークウィジェットを他にどのように配置しますか？他の唯一の方法は、XMLを取得して解析することですが、当然のことながら、関連する天気のグラフィックスをスローする条件が必要です...それほど価値はありませんが、時間があれば、よりクリーンです。

元のフレームセットモデル（フレームセットとフレーム要素）は、使いやすさの点で非常に悪かったです。IFrameは、元のフレームセットモデルほど多くの問題を抱えていなかった後の発明ですが、欠点があります。

ユーザーがIFrame内をナビゲートできるようにすると、リンクとブックマークは期待どおりに機能しません（iframeのURLではなく、外部ページのURLをブックマークするため）。

メインページがHTTPプロトコルで読み込まれ、ページの一部がHTTPSプロトコルで動作する必要がある場合、iFrameはjsonpの手を打つことができます。

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

ですから、iFrameは悪ではありません。

それらは悪くはありませんが、実際には役に立ちます。少し前に、Twitterフィードを埋め込む必要があり、mdが同じページでmdを実行できないという大きな問題があったため、別のページに設定して、iframeとして配置しました。

すべてのブラウザー（および電話ブラウザー）がそれらをサポートしているため、これらも優れています。それらを正しく使用する限り、それらは悪い習慣と見なすことはできません。

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

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

それはすべてあなたの要件に依存すると私は言うでしょう。ページがすべてのブラウザで同等に機能することを確認したい場合は、IFRAMEを避けてください。ターゲットが絞られていて、よく知られているオーディエンス（ローカルイントラネットなど）を対象としていて、IFRAMEを使用するメリットがある場合は、そうしても問題ないと思います。