javascript - iframe はひどいアイデアですか?

Question

私はウィジェットを作成しており、その中にコンテンツを表示するために iframe を使用しています。ある時点で、サードパーティの HTML と JS の提供を開始する可能性があるため、iframe を使用することをお勧めします。

ウィジェットの JavaScript が少し複雑になるので、これが最適な実装ではないのではないかと心配しています。

何かアドバイスはありますか？他の人が iframe についてどう思うかを聞くことは大きな助けになるでしょう。

score 24 · Accepted Answer

いいえ、iframe に問題はありません。サードパーティのコンテンツの提供を開始する場合は、iframe を使用することをお勧めします。

今後の HTML5 仕様では、このような状況に備えて iframe にさらに多くのセキュリティ機能を組み込むことも計画されているため、今でもそれらを使用することをお勧めします。

score 11 · Accepted Answer

XMLHTTPRequestが広く使用されるようになる前は、JavaScriptとiframeの組み合わせを使用して、ページ全体を更新せずに動的にコンテンツを提供していました。

この方法でサイトを開発することについてはたくさんの情報があるので、あなたはそれがあなたがぶつかる可能性のある多くの障害への回避策を見つけるのに比較的簡単な時間を持っているべきです。

私が苦痛だと思ったのは、iframeでのJavaScriptのクロスドメイン使用です。iframeに埋め込んだページが「親」ページとは異なるドメインからのものである場合、ブラウザには、一方から他方へのアクセスを許可することに対するセキュリティ制限があります。秘訣は両方のページが宣言することです

document.domain = 'somedomain.com';

この種の回避策については、Web上にたくさんのものがあります。

幸運を！

score 8 · Accepted Answer

最近私が発見したことの1つは、iframe内に埋め込まれた.aspxページで、Cookieが失われる問題が発生することがあり、それが、私が関わったアプリケーションのセッション状態の損失につながることです。

私にとっては、別の開発ショップが自分のページで自分の.aspxページの1つを消費しているシナリオでした。これは、私たちが別のサーバーを使用していたことを意味します。

どうやらこれは、親ページが子ページのCookieを拒否したことが原因でした...セッションCookieと同様に、セッションも同様です。

これがどのように機能するかについての特定の仕組みは少し複雑です：詳細

この問題はFireFoxに影響を与えませんでしたが、IE7に現れ、数時間は本当の謎でした。

また、上記でリンクした記事と一点矛盾しなければなりません。記事には、含まれているページが.aspxでもある場合、これは取得されないと書かれています...この場合、両方のページが.aspxであるため、これは当てはまりません。

それは、この記事がこの状況について述べている他のすべてに疑問を投げかけますが、それは解決につながったので、それもまた何かです。

記事が示唆しているように、私は次のコードを挿入しました。これは、ページのInitイベントにp3p（プライバシー設定プロジェクト-聞いたことがありません）ヘッダーを挿入します。

HttpContext.Current.Response.AddHeader("p3p", "CP=\""IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT\""")

...そしてそれで問題は解決しました。

score 6 · Accepted Answer

私は大多数の意見に同意せず、そうです、iframe は絶対にひどい考えだと言います。Web デザインコミュニティでしばらく働いたことがある人なら誰でも、iframe は純粋な悪であり、絶対に必要でない限り避けるべきであることに同意するでしょう。

それらが悪いと私が信じる理由は、それらが Web ページのナビゲーションパターンを壊すからです。iframe を使用すると、ブラウザーの戻るボタンと進むボタンを効果的に壊して、ユーザーを混乱させることができます。これは、HTTP プロトコルの背後にある考え方全体を壊します。URL が常に一意の場所につながること。iframe が馬だったら、ずっと前に引退していたでしょう。コンテンツを動的に提供する方法は他にもあり、代わりにこれらを使用する必要があります。

ウィジェットを作成している場合、iframe を使用することに関する差し迫った懸念は解消されますが (検索エンジンに悪い、ブックマークに悪いなど)、どちらの方法でも、コンテンツは iframe ではなく動的に、または新しいウィンドウでより適切に提供されます。

score 5 · Accepted Answer

私が知っている彼らの「本当に悪い」ことは1つだけです。

サードパーティがJavaScriptを実行すると、DOMの変更が少し早すぎます... IE6とIE7は、非常に役に立たない「操作が中止されました」エラーをスローし、iframeだけでなく周囲のページ全体を空白にします。（たとえば、サイトが下に表示されます）

IE8では修正されていませんが、クラッシュはより適切に処理されます。

score 4 · Accepted Answer

個人的には、あまり面倒なことをせずにできれば避けたいと思います。Javascript（または動的にロードする必要がある場合はAJAX）を使用すると、divを使用して必要に応じてコンテンツを変更するだけで、非常に簡単になります。場合によっては、柔軟性が大幅に向上し、JSが簡素化されます。ウィジェットとページの残りの部分との間の相互作用の。

そうは言っても、私は両方のオプションを調査します。JSパスがトリッキーまたは複雑すぎると思われる場合は、iframeを使用してください。

score 4 · Accepted Answer

私の経験では、iframe はハックまたは時間の節約になります。iframe を使用している場合は、それらの理由から必要であることを確認してください。コンテンツを制御できる (またはミラーリングやスクレイピングによって制御できる) 場合は、AJAX またはサーバー側のインクルードを使用して、外部データをページにプルしたり、ページからプッシュしたりすることを検討する必要があります。堅牢で、最終的に管理が容易になります。

score 2 · Accepted Answer

フレームと同様に、iframeは目前のタスクに使用するコントロールにすぎません。そのため、それ自体は良いことでも悪いことでもありませんが、目前のタスクとクライアントの要件に基づいて、良いことも悪いこともあります。私の知る限り、最近のすべてのブラウザー（およびLinux以外のユーザー）は、問題なくiframeを「表示および使用」できます。

score 2 · Accepted Answer

ウィジェットが何をするかによって異なります。iframe には適切な場所がありますが、(js をより複雑にすることは言うまでもなく) レイアウトの頭痛の種となることはほとんどないため、絶対に必要でない限り、ほとんどの人はそれらを避ける傾向があります..

score 1 · Accepted Answer

良いオプションは、overflow CSS プロパティを使用することです。デフォルト値は表示されていますが、非表示、スクロール、または自動に設定できます。あなたの場合は auto を使用します。コンテンツが大きくなりすぎると、iframe があるように見えますが、それでもページには正しく表示されます。

参照:オーバーフロープロパティ

score 1 · Accepted Answer

iframe は悪ではありません。他のツールと同様に単なる別のツールであり、そのメリットを判断するには、それらが使用されるコンテキストを判断する必要があります。Google 画像検索、および他のいくつかの有名なサイトでは、限られた目的で iframe を使用しています。

一般に、それらはブランディングのために使用されるか、ユーザーをサイト外にリダイレクトするサイトにユーザーが戻ることができるようにするために使用されます。

ページが提供されている外部のドメインを参照する iframe などのクロスドメイン iframe を使用している場合、セキュリティ上の理由から設計上制限されており、関連付けられているドメイン外の DOM の内部に JavaScript を介してアクセスすることはできません。

また、多くのサイトではサイトの埋め込みが妨げられており、iframe がストライプ化されています (トップ URL がドメインにリダイレクトされます)。

score 0 · Accepted Answer

技術的には、iFrameには他の方法よりも悪いことは何もありません。しかし、意味的には、悪があります。

WebはHTTPに基づいています。これは、特定のURLが常に一意のリソースにつながるというプロトコルです。

iFrameを使用すると、すべてのURLの背後にあるWebページに溶け込んだ複数のリソースを提供するだけです。Webがどのように成長するかについて懸念がある場合、それは面倒です。さらに、検索エンジンロボットにとって、それはトリッキーです。

score 0 · Accepted Answer

iframe 内のコンテンツが予測可能である限り、必ずしもそうとは限りません。

score 0 · Accepted Answer

iframe には、使いやすさとアクセシビリティの問題がいくつかあります。一部のブラウザーとスクリーンリーダーは iframe を表示できないため、代替コンテンツを提供する必要があります。

<iframe src="content.html">
    <p>
        This content will only be displayed by browsers that do not support
        iframes. You should provide a link to the content, or in your 
        case an alternative way to use your widget.
    </p>
</iframe>

サードパーティのコンテンツの提供を開始する場合は、読み込みが完了した後に iframe がフォーカスを取得することに注意する必要があります。通常のユーザーにとっては少し面倒ですが、スクリーンリーダーでブラウジングしているユーザーにとっては非常に混乱する可能性があります.

score 0 · Accepted Answer

ほとんど言及されていないiframeには重大な問題がありますが、それは私を悩ませています。

私たちの同僚は、動的に変化するデータベースに投資する生涯の仕事をしており、それを Google ドキュメントのスプレッドシートに読み込んでから、多くのサポート資料と一緒にサイトに表示しています。

誰かが私のページソースから iframe コードを取得し、それを自分のページに押し込むのを止める方法はまったくありません。現在、彼らは私たちのすべてのデータを取得しており、数分前までに更新され、ページにまったく何も提供されていません.

Google の iframe を特定のドメインに関連付けることができれば、その追跡は停止します。

アイデアはありますか、明るい火花はありますか？

score 0 · Accepted Answer

Re: 「HTTP プロトコルの背後にある全体的な考え方。URL は常に一意の場所につながる」

セキュリティとスケーラビリティのために、同じ URL から CMS 全体を提供しています (ほとんどの場合、GET パラメーターの代わりに POST を使用しています)。安全なコンテンツを認証なしで表示したくありません。新しいページごとに認証について心配する必要がないため、ディスパッチシステムにより開発が容易になります。

また、SEO が適用されないアプリケーションもあります (Web ベースの ERP など)。

PHP で生成されたアセンブリツリーからコンテンツを提供するために iFrame を使用しています。ユーザーがパーツ/アセンブリの詳細を表示するたびに、ツリー (およびノードの表示) を更新したくありません。

javascript - iframe はひどいアイデアですか?

16 に答える 16

Related

Reference