それについて矛盾したメッセージを取得し、そうでないことを願っています。膨大な数のサイトで使用されているため、サポートが停止することは想像できません。
それに関するいくつかの追加の質問:
私の意見では、W3CはStrict HTMLおよびXHTML Doctypeからiframeをダンプする際に銃を飛ばしました。理論的には、<object>
要素を使用してドキュメントに外部オブジェクトを追加しますが、ブラウザの違いと制限により、多くの開発者にとってこれは初心者ではありません。はるかに実用的なHTML 5(まだドラフト)では、iframeが復活し、2つの新しい属性seamless
と興味深いsandbox
を備えています。
<iframe>
のサポートはHTML 5にまだ存在しているため、近い将来これが変わるとは思いません。
他の質問に答えるには:
<iframe>
s(一般的なフレームとして)は、ほとんどの場合ユーザーフレンドリーではありません:<div>
明確にするために、私は<iframe>
をインターフェース要素として話しています。たとえば、他のものをロードするための隠された要素ではありませんGoogle Mailはそうです。
IFrameは時代遅れではありませんが、それらを使用する理由はまれです。
Iframeを使用する理由:
また、iframeを削除する必要はありません。これは必要なタグであり、しばらくは使用されます。
Iframes 廃止ページレイアウト用。適切なCSSレイアウトの代わりにそれらを使用しないでください。テーブルベースのレイアウトの方が優れています。
Iframeを使用する理由は次のとおりです。
IFrameの代わりにObjectタグを提案するフォーラムをたくさん見ましたが、ほとんどの場合はおそらく動作します。
たとえば、IFrameでPDFを表示しています(PDF以外にもページに表示する必要がある他の要素があるため)で、Objectを使用して正常に表示することができました。
何だった:
<iframe id="confirmed_pdf" class="current_pdf" src="/prescriptions/show_pdf?id=123" height="570" width="480"></iframe>
なりました:
<object id="confirmed_pdf" class="current_pdf" data="/prescriptions/show_pdf?id=123" type="application/pdf" height="570" width="480">
<p>[Show this message if displaying the PDF did not work]</p>
</object>
しかし、Objectは、PDFページの一部のみを印刷できるという要件を満たすための適切な代替ではありませんでした。
IFrameは、ページ内の独自のウィンドウ(基本的にはウィンドウ内のウィンドウ)に似ており、ウィンドウオブジェクトを取得したら、次のように.print()を呼び出すことができます。
jQuery("#confirmed_pdf").contentWindow.print();
IFrameにはcontentWindowプロパティがあります。これにより、その部分のみを印刷できます。オブジェクトにはcontentWindowプロパティがないため、ページのセクションのみを印刷する方法はありません。
そのため、IFrameを使用して何かを表示するだけの場合、代わりに使用できるObjectなどの他のタグがあるようです。ただし、特定の方法でIFrameのコンテンツを操作する必要がある場合は、IFrameが必要になる場合があります。
IFramesは死んでいませんが、Frameset/Framesは死にかけています。
[〜#〜] ie [〜#〜](IE7/IE8)の最後の2つのリリースでは、フレーム(IFrameではない)のズームが悲惨な結果をもたらしました。
どうしてもIFrameを使用しますが、IMHOはフレームセット/フレームを避けます。
IFrameはAJAXで頻繁に使用されます。たとえば、GMailでは、9つの非表示のIFrameを使用しています。
前の会社で、顧客が自分のWebサイトに統合するホストアプリケーションを提供しました。時には、IFrameを使用してこれを行い、ホストされているページを既存のデザインに合わせます。これはシームレスに行われることもありました(つまり、IFrameには境界線やスクロールバーがなく、ページの一部のように見えました)。これはタグの良い使い方だと考えました。
コース用の馬... <iframe>は他のものと同じです...正しい目的のためには、正しいツールです。間違った目的のために、彼らはいハック、またはさらに悪いことです。
Ajaxでは、多くの場合、<div>がより適切なコンテナーです。一部の場所では、<iframe>でサポートされているように、自分のサイトの一部として外部コンテンツを偽装する活動は不適切です。
私のチームは先日、ユーザーにHTML電子メール履歴へのアクセスを提供する理想的な方法として<iframe>を使用しました。電子メールは完全な<html>ページで、Webテンプレートに簡単に挿入できました。 <iframe>は、そのデータを提示するのに完全に完璧でした] '。
一方、<iframe>は、サイトに出力されるユーザー送信コンテンツでは、ほとんどの場合削除または無効にする必要があります。そのコンテキストでは、これらが主要なセキュリティ問題であるためです。
状況によっては非常に便利ですが、制限があります。特に、複数のサイトに共通の機能を埋め込みます。
たとえば、私は多くのスコットランド商品のeコマースサイトを運営しているクライアントがいます。この一環として、姓またはタータンの選択から可能性のある氏名を特定するための簡単なアプリケーションをいくつか開発しました(タータンは私たちの経済にとって年間7億ドルの価値がありますが、お望みならクスクスしてください)。この背後のデータベースは驚くほど大きく(コア名とtartansテーブルの1万行近く)、かなり定期的に更新されています。
そのため、1つのWebサイトで実行するようにアプリケーションを設定し、iframeを使用してこれらを他のWebサイトに埋め込み、単純なjavascriptパラメーターの受け渡しを可能にして、タータンまたはクランの選択を埋め込みサイトの機能と統合できるようにします。 iframeはnoborderとして設定されているため、エンドユーザーには完全にシームレスに表示されます。
もちろん、これを行う方法は他にもありますが、iframeの使用は簡単で堅牢です。そして、それは確かに時代遅れではありません。
現在、Googleガジェットの仕様はiframeに依存しています: http://code.google.com/apis/gadgets/docs/spec.html
現在、これらは複数のドメイン/プロバイダーからプルされたJavaScriptアプリを分離するための唯一の簡単な方法です。
また、サードパーティからWebサイトに埋め込まれたウィジェットの多くは、iframeを使用しています。
Iframeには欠点がありますが、Webの一般的な問題に対する実用的なソリューションを提供します。私は彼らが来てしばらくの間存在することを推測する必要があります。
コンプライアンスとセキュリティの問題により、iframeを使用するようになります。ショッピングカートは、支払い処理側のすべての責任を負うことなく、一部のWebページの一部としてショッピングカートを視覚的に組み込む場合の一般的なIFrameベースの実装です。
通常、iコマースを提供して、eコマースとクライアントを統合し、ターンキーの可能性を高めます。
通常のフレームでは必要なことができないため、サイトを通常のフレームセットからIframeに変更しました。コードベースの残りの部分で問題は発生しませんでした。
私は、.net Webフォームの複雑さをカバーするためだけに、プルダウンメニュー、リスト、コンテンツブロックなどのすべてにフレームを使用している会社で働いています。アプリケーションは非常に遅く、IEでのみ実行されます。これをしないでください。