iframe 要素

4.8.2 iframe 要素

カテゴリー
フロー・コンテンツ
フレージング・コンテンツ
エンベッディッド・コンテンツ
インタラクティブ・コンテンツ
この要素を使うことができるコンテキスト：
エンベッディッド・コンテンツが期待される場所
コンテンツモデル：
本文で説明する要件に準拠するテキスト
コンテンツ属性：
グローバル属性
src
srcdoc
name
sandbox
seamless
width
height
DOMインタフェース：
interface HTMLIFrameElement : HTMLElement {
           attribute DOMString src;
           attribute DOMString srcdoc;
           attribute DOMString name;
  [PutForwards=value] readonly attribute DOMSettableTokenList sandbox;
           attribute boolean seamless;
           attribute DOMString width;
           attribute DOMString height;
  readonly attribute Document contentDocument;
  readonly attribute WindowProxy contentWindow;
};

iframe 要素は、ネストされたブラウジング・コンテキストを表します。

src 属性には、ネストされたブラウジング・コンテキストに入れるページのアドレスを指定します。この属性を指定するなら、 潜在的にスペースで囲まれた空でない妥当な URL でなければいけません。

srcdoc 属性には、ネストされたブラウジング・コンテキストに入れるページのコンテンツを指定します。この属性の値は、iframe srcdoc ドキュメントです。

HTML ドキュメントの iframe 要素では、この属性を指定するなら、その値は、次に示す構文上のコンポーネントから構成された HTML 構文を使った値でなければいけません。順番も次に示すとおりでなければいけません：

  1. 任意の数のコメントとスペース文字
  2. オプションで、DOCTYPE
  3. 任意の数のコメントとスペース文字
  4. ルート要素。html 要素 が相当します。
  5. 任意の数のコメントとスペース文字

XML ドキュメントの iframe 要素では、この属性を指定するなら、その値は、XML 仕様にある document と表記された生成規則に一致しなければいけません。[XML]

src 属性と srcdoc 属性の両方が指定された場合、srcdoc 属性が優先されます。こうすることで、ウェブ制作者は、srcdoc 属性をサポートしていない古いユーザーエージェントに対してフォールバック URL を提供できます。

iframe 要素が初めてドキュメントに挿入されるとき、ユーザーエージェントは、ネストされたブラウジング・コンテキストを生成しなければいけません。その後に初めて iframe 属性を処理しなければいけません。

ネストされたブラウジング・コンテキストを持った iframe 要素に srcdoc 属性がセットされたり変更されるたびに、ユーザーエージェントは iframe 属性を処理しなければいけません。

同様に、ネストされたブラウジング・コンテキストを持つものの、srcdoc 属性が指定されていない iframe 要素に、src 属性がセットされたり変更されるたびに、ユーザーエージェントは iframe 属性を処理しなければいけません。

ユーザーエージェントが iframe 属性を処理することになったら、次のリストから最初の適切な手順を実行しなければいけません：

srcdoc 属性が指定された場合

該当の要素のブラウジング・コンテキストを、Content-Type が text/html で、URL が about:srcdoc で、データがこの属性の値から構成されるリソースへナビゲートします。結果として得られた Document は iframe srcdoc ドキュメントと見なされなければいけません。

src 属性が指定され、srcdoc 属性が指定されない場合

  1. src 属性の値が空文字列なら、下記の empty 手順に飛びます。

  2. src 属性の値を、iframe 要素に対して解決します。

  3. 成功しなかったら、下記の empty 手順に飛びます。

  4. 結果となる絶対 URL が文字列 "about:blank" に大文字・小文字を区別せず一致し、ユーザーエージェントが初めてこの iframe の属性を処理するなら、下記の empty 手順に飛びます。(初めてでない場合は、通常通り、about:blank がロードされます。)

  5. この要素のブラウジング・コンテキストを、結果となる絶対 URL へナビゲートします。

Empty:上記の手順でユーザーエージェントが empty 手順へ飛ぶ場合、ユーザーエージェントが初めてこの iframe の属性を処理しているところであれば、ユーザーエージェントは、その iframe 要素で load という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。(この手順に飛んだ後、上記の手順は再開されません。)

それ以外の場合

その iframe 要素で load という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

iframe 属性を処理するアルゴリズムでユーザーエージェントの要件となるあらゆるナビゲーションは、その iframe 要素のドキュメントのブラウジング・コンテキストをソース・ブラウジング・コンテキストとして完了されなければいけません。

さらに、iframe 属性を処理するアルゴリズムが呼び出されたときにブラウジング・コンテキストのセッション履歴が一つの Document しか含んでおらず、それが、そのブラウジング・コンテキストが生成されたときに生成された about:blank Document だったなら、そのアルゴリズムにおいてユーザーエージェントに求められるあらゆるナビゲーションは、replacement enabled で完了されなければいけません。

もし、この要素が生成されたときに、srcdoc 属性がセットされていなかった上に、src 属性がセットされていない、もしくは、その値が解決できなかったら、そのブラウジング・コンテキストは、当初の about:blank ページのままとなるでしょう。

もし、ユーザーがこのページからナビゲートして離れたら、その iframe に対応する WindowProxy オブジェクトは、新規の Document オブジェクトのために、新たな Window オブジェクトをプロクシします。しかし、src 属性は変更されません。

Document から iframe を削除しても、そのブラウジング・コンテキストは破棄されることはありません。実際に、iframe のブラウジング・コンテキストは、その iframe が他の Document に移動されると、その元の親の Document より長く存続することができます。

一方で、iframe が Document から削除され、それに続いて、ガーベッジ・コレクションが実行されるなら、これは、子のブラウジング・コンテキストの WindowProxy オブジェクトはガーベッジ・コレクションの対象になることを意味することが想定されます（他にリファレンスが存在しない場合）。それから、そのブラウジング・コンテキストは破棄されることになり、それから、その Document も破棄されることになります。これは、その Document で実行されているスクリプトに通知されること無しに発生します。例えば、unload イベントは発出されません（"ドキュメントをアンロードする" 手順は実行されません）。

ここでは、ブログに、sandbox と seamless 属性と一緒に srcdoc 属性が使われています。これらについては後述します。この機能をサポートするユーザーエージェントのユーザーは、ブログ投稿のコメントへのスクリプト・インジェクションから守られます：

<article>
 <h1>I got my own magazine!</h1>
 <p>After much effort, I've finally found a publisher, and so now I
 have my own magazine! Isn't that awesome?! The first issue will come
 out in September, and we have articles about getting food, and about
 getting in boxes, it's going to be great!</p>
 <footer>
  <p>Written by <a href="/users/cap">cap</a>.
  <time pubdate>2009-08-21T23:32Z</time></p>
 </footer>
 <article>
  <footer> At <time pubdate>2009-08-21T23:35Z</time>, <a href="/users/ch">ch</a> writes: </footer>
  <iframe seamless sandbox srcdoc="<p>did you get a cover picture yet?"></iframe>
 </article>
 <article>
  <footer> At <time pubdate>2009-08-21T23:44Z</time>, <a href="/users/cap">cap</a> writes: </footer>
  <iframe seamless sandbox srcdoc="<p>Yeah, you can see it <a href=&quot;/gallery?mode=cover&amp;amp;page=1&quot;>in my gallery</a>."></iframe>
 </article>
 <article>
  <footer> At <time pubdate>2009-08-21T23:58Z</time>, <a href="/users/ch">ch</a> writes: </footer>
  <iframe seamless sandbox srcdoc="<p>hey that's earl's table.
<p>you should get earl&amp;amp;me on the next cover."></iframe>
 </article>

引用符をエスケープしなければいけない（そうしないと、sandbox 属性が途中で終わってしまうことになります）点と、サンドボックス化されたコンテンツに入れられたアンパサンド（例えば URL や散文の中で）は二重にエスケープしなければいけない点に注意してください。 — そうすることで、当初 sandbox 属性のパース時に、そのアンパサンドが保たれます。また、サンドボックス化されたコンテンツのパース時に、そのアンパサンドの誤解釈を防ぐことができます。

HTML 構文では、ウェブ制作者は、U+0022 QUOTATION MARK 文字 (") を使ってこの属性のコンテンツを囲み、すべての U+0022 QUOTATION MARK (") と U+0026 AMPERSAND (&) 文字をエスケープし、sandbox 属性を指定し、必ず組み込むコンテンツが安全になるようにすることを忘れないようにする必要があります。

Due to restrictions of the XML syntax, in XML the U+003C LESS-THAN SIGN character (<) needs to be escaped as well. In order to prevent attribute-value normalization, some of XML's whitespace characters — specifically U+0009 CHARACTER TABULATION (tab), U+000A LINE FEED (LF), and U+000D CARRIAGE RETURN (CR) — also need to be escaped. [XML]

name 属性が指定されたら、それは、妥当なブラウジング・コンテキスト名でなければいけません。指定された値は、ネストされたブラウジング・コンテキストを名付けるために使われます。ブラウジングコンテキストが生成されたとき、この属性が存在すれば、そのブラウジング・コンテキスト名は、この属性の値となるようセットされなければいけません。そうでなければ、そのブラウジング・コンテキスト名は空文字列となるようセットされなければいけません。

name 属性がセットされたら常に、ネストされたブラウジング・コンテキストの名前は、新しい値に変更されなければいけません。この属性が削除されたら、ブラウジング・コンテキスト名は空文字となるようセットされなければいけません。

コンテンツが iframe 要素にロードするとき、そのコンテンツ内で load イベントが発出された後に、ユーザーエージェントは、iframe 要素で load という名のシンプルなイベントを発出するタスクをキューイングしなければいけません。コンテンツの URL が iframe 要素の Document と同じオリジンを持ち、そのコンテンツが、ロードに失敗（例えば、DNS エラー、ネットワークエラーや、サーバーが 4xx or 5xx に相当するステータス・コードを返したとき）したとき、ユーザーエージェントは、代わりに、その要素で error という名前のシンプルなイベントを発出するタスクをキューイングしなければいけません。

これらのタスクに対するタスク・ソースは、DOM マニュピュレーション・タスク・ソースとなります。

iframe 要素が生成されるときも、その中に他にロードするデータがないのであれば、load イベントが発出されます。

iframe 要素にアクティブなパーサがあり、iframe 要素のブラウジング・コンテキストのアクティブなドキュメントの load イベントを遅らせるようなものが iframe 要素にあるとき、その iframe 要素は、そのドキュメントの load イベントを遅らせなければいけません。

もし、load イベントの処理中に、iframe 要素のブラウジング・コンテキストが再びナビゲートされたら、それはさらに load イベントを遅らせることになります。

sandbox 属性を指定すると、その iframe によって組み込まれたコンテンツ上に制限を組み合わせて加えることができます。この値は、ユニークなスペース区切りトークン非順序セットでなければいけません。大文字・小文字は区別されません。指定可能な値は、allow-same-origin, allow-top-navigation, allow-forms, and allow-scripts です。この属性がセットされたら、そのコンテンツは、ユニークなオリジンからのものであるととして扱われ、フォームとスクリプトは無効にされ、別のブラウジング・コンテキストを指しているリンクは無効になり、プラグインは無効になります。allow-same-origin キーワードを指定すると、強制的にユニークなオリジンとせずに、同じオリジンからのものと扱われるようになります。allow-top-navigation キーワードを指定すると、そのコンテンツからトップレベル・ブラウジング・コンテキストをナビゲートできるようにします。allow-forms と allow-scripts キーワードを指定すると、それぞれ、フォームとスクリプトを再び有効にすることができます（とはいえ、スクリプトからのポップアップ生成は阻止されます）。

組み込まれたページが、iframe を含んでいるページとして同一オリジンを持つとき、allow-scripts と allow-same-origin の両方をセットしたとしても、その組み込まれたページは、単に sandbox 属性を削除できるようになるだけです。

アタッカーが、iframe の中ではなく、その悪意のあるコンテンツに直接ユーザーを誘導することさえできれば、たとえその悪意のあるコンテンツをサンドボックス化したとしても、さほど助けにはなりません。悪意のある HTML コンテンツによって引き起こされうるダメージを抑えるためにも、text/html-sandboxed MIME タイプを使って、そのコンテンツを送出するべきです。

sandbox 属性が指定されているなら、その iframe 要素のネストされたブラウジング・コンテキストは、下記のリストに挙げたフラグをセットしなければいけません。さらに、iframe の中にネストされたブラウジング・コンテキストは、直接的か間接的かにかかわらず、その iframe の Document が生成されたときに、その iframe の Document のブラウジング・コンテキスト上でセットされたように、それらの上ですべてのフラグをセットしなければいけません。

サンドボックス化ナビゲーション・ブラウジング・コンテキスト・フラグ

このフラグは、サンドボックス化されたブラウジング・コンテキスト（または、さらに、その中にネストされたブラウジング・コンテキスト）以外のブラウジング・コンテキスト、および、トップレベル・ブラウジング・コンテキスト（次で定義されたサンドボックス化トップレベル・ナビゲーション・ブラウジング・コンテキスト・フラグによってほぞされます）を、コンテンツからナビゲートできないようにします。

このフラグはまた、target属性や、window.open() メソッドなどを使って、付随するブラウジング・コンテキストを新規に生成できないようにもします。

サンドボックス化トップレベル・ナビゲーション・ブラウジング・コンテキスト・フラグ：sandbox 属性の値をスペースで区切った際に、allow-top-navigation キーワードが見つかった場合を除く

このフラグは、コンテンツからトップレベル・ブラウジング・コンテキストをナビゲートできないようにします。

allow-top-navigation がセットされたら、コンテンツは、そのトップレベル・ブラウジング・コンテキストをナビゲートすることができます。しかし、他のブラウジング・コンテキストは、前に定義されたサンドボックス化ナビゲーション・ブラウジング・コンテキスト・フラグによって保護されたままとなります。

サンドボックス化プラグイン・ブラウジング・コンテキスト・フラグ

このフラグは、 embed 要素, object 要素, applet 要素を使おうが、ネストされたブラウジング・コンテキストのナビゲーションを通してだろうが、コンテンツがプラグインのインスタンスを生成できないようにします。

サンドボックス化シームレス iframe フラグ

このフラグは、コンテンツが、子孫の iframe 要素で seamless 属性を使うことができないようにします。

これによって、allow-same-origin を使って挿入されたページでは、CSS セレクタ・ベースのメソッドを使って同じサイトにある別のページの DOM を探査できないようになります（特に、ユーザー・センシティブな情報）。

サンドボックス化オリジン・ブラウジング・コンテキスト・フラグ：sandbox 属性の値をスペースで区切った際に、allow-same-origin キーワードが見つかった場合を除く。

このフラグは、ユニークなオリジンにコンテンツを押し込みます。そのため、同じオリジンにある別のコンテンツにアクセスできないようなります。

このフラグはまた、document.cookie IDL 属性の読み書きをできないようにします。そして、localStorage へのアクセスをブロックします。[WEBSTORAGE]

allow-same-origin 属性は 2 つの場合を想定しています。

まず一つ目として、同じサイトのコンテンツをサンドボックス化して、そのスクリプティングを無効にしつつも、そのサンドボックス化されたコンテンツのDOMに対してはアクセスができるようにするために使うことができます。

二つ目として、サードパーティのサイトからのコンテンツを組み込んだ際に、そのサイトはポップアップウィンドウを開くことができないようサンドボックス化されますが、データを蓄積するために database API などを使って、組み込まれたページがそのもととなるサイトと通信できるようにするために使うことができます。

サンドボックス化フォーム・ブラウジング・コンテキスト・フラグ：sandbox 属性の値をスペースで区切った際に、allow-forms キーワードが見つかった場合を除く。

このフラグは、フォーム・サブミットをブロックします。

サンドボックス化スクリプト・ブラウジング・コンテキスト・フラグ：sandbox 属性の値をスペースで区切った際に、allow-scripts キーワードが見つかった場合を除く。

このフラグは、スクリプトの実行をブロックします。

サンドボックス化オートマチック・フィーチャー・ブラウジング・コンテキスト・フラグ：sandbox 属性の値をスペースで区切った際に、allow-scripts キーワード（前に定義したものです）が見つかった場合を除く。

このフラグは、自動的に起動する機能をブロックします。例えば、自動的にビデオの再生を開始したり、自動的にフォーム・コントロールをフォーカスする、といったものです。これは、スクリプトと同じフラグによって緩和されます。なぜなら、スクリプトが有効な場合、いずれにせよ、これらの機能はあきらかに実現可能であり、そして、ウェブ制作者に対して、サンドボックス化されたときに、それらをするためにスクリプトを使うよう強要するのは難しいからです。

こららのフラグは、上記にリストされた条件でセットされるものとして定義されていない限り、セットされてはいけません。

これらのフラグは、iframe のネストされたブラウジング・コンテキストがナビゲートされるときだけに作用します。sandbox 属性の値を削除したり、この属性そのものを削除したとしても、すでにロードされたページには何も作用しません。

この例では、完全に不明で、敵対の可能性があり、ユーザーが提供したHTMLコンテンツがページに組み込まれています。そのコンテンツはサンドボックス化されているため、ユーザーエージェントは、そのコンテンツが同じサイトから供給されているにもかかわらず、そのコンテンツをユニークな origin からのものであるとして扱います。ゆえに、それは、すべての通常のクロスサイト制限の影響を受けます。さらに、組み込まれたページのスクリプトとプラグインとフォームは無効化され、それ自身ではない他のフレームやウィンドウをナビゲートすることはできません（または、それ自身が組み込んでいるあらゆるフレームやウィンドウ）。

<p>We're not scared of you! Here is your content, unedited:</p>
<iframe sandbox src="getusercontent.cgi?id=12193"></iframe>

cookie は、 document.cookie IDL 属性では見えませんが、getusercontent.cgi のリクエストでサーバに送信されますので、注意してください。

サーバーが、text/html-sandboxed MIME タイプを使ってユーザーから提供された HTML を送信することが重要です。そうすることで、あらゆる攻撃に対してユーザーを脆弱にするようなページに、アタッカーがユーザーを直接的に誘導しようとしても、そのページは、そのサイトのオリジンのコンテンツ内で実行されません。

この例では、他のサイトからのガジェットが組み込まれています。このガジェットはスクリプティングとフォームが有効になっています。オリジン・サンドボックス制限が適用されますが、そのガジェットは、そのもととなるサーバと通信することができます。それでもなお、サンドボックスは役に立っているのです。それは、プラグインとポップアップを無効にするからです。ゆえに、ユーザーがマルウェアや他の厄介者にさらされるリスクを低減します。 

<iframe sandbox="allow-same-origin allow-forms allow-scripts"
        src="http://maps.example.com/embedded.html"></iframe>

ファイル A が次のコードを含んでいるとします：

<iframe sandbox="allow-same-origin allow-forms" src=B></iframe>

また、ファイル B が iframe を含んでいるとします：

<iframe sandbox="allow-scripts" src=C></iframe>

さらに、ファイル C がリンクを含んでいるとします：

<a href=D>Link</a>

この例では、すべてのファイルが text/html として送信されるとします。

このシナリオでは、ページ C はすべてのサンドボックス・フラグがセットされます。スクリプトは無効になります。なぜなら、A の iframe のスクリプトは無効にされているからです。そして、これは、B の iframe にセットされた allow-scripts キーワードより優先されます。フォームも無効になります。なぜなら、内部の iframe (B の中) には allow-forms キーワードがセットされていないからです。

では、次に、A からスクリプトを使って A と B の sandbox 属性をすべて削除したとしましょう。すると、すぐには何も変化は起こりません。もし、ユーザーが C のリンクをクリックしたら、B の iframe にページ D がロードされますが、ページ D は、B の iframe に allow-same-origin と allow-forms キーワードがセットされているかのように振る舞います。なぜなら、ページ B は、ロードされたときは、A の iframe にネストされたブラウジング・コンテキストの状態だったからです。

一般的には、動的に sandbox 属性を変更したり削除したりするのは賢明ではありません。なぜなら、そうしたとしても、何が許可され、何が許可されないのかについて判断するのは、相当に難しくなるからです。

潜在的に、悪意のあるファイルが、text/html ではなく text/html-sandboxed としてラベリングされて、iframe 要素を含んでいるファイルとして、同じサーバーから送信されることも考えられます。だとしても、確実に、そのファイルのスクリプトからそのサイトを攻撃できないようになります（あたかも実際にはそれらが別のサーバーから送信されたかのように扱われます）。たとえ、ユーザーが直接的にそれらのページを訪問してしまうよう罠を仕掛けられたとしてもです。そして、sandbox 属性による保護がなかったとしてもです。

もし allow-scripts キーワードが allow-same-origin キーワードと一緒にセットされ、そのファイルが iframe の Document と同じオリジンからのものであれば、その"サンドボックス化"された iframe のスクリプトだけが、sandbox 属性にアクセスでき、それを削除でき、そして、リロードすることで、事実上、サンドボックスを完全に破ることができるでしょう。

seamless 属性は論理属性です。これが指定されると、iframe 要素のブラウジング・コンテキストは、ドキュメントの一部にそれが現れるようにレンダリングされるということを示します（親のドキュメントに、境目がないかのように組み込まれます）。特に、この属性が iframe 要素にセットされ、そのオーナーの Document のブラウジング・コンテキストが、その Document が生成されたときにサンドボックス化シームレス iframe フラグがセットされず、一方で、ブラウジング・コンテキストのアクティブ・ドキュメントがその iframe 要素のドキュメントと同じオリジンを持つ場合、または、ブラウジング・コンテキストのアクティブ・ドキュメントの address がその iframe 要素のドキュメントと同じオリジンを持つ場合、次の要件が適用されます：

  • ユーザーエージェントは、そのブラウジング・コンテキストに対して、シームレス・ブラウジング・コンテキスト・フラグを true にセットしなければいけません。これは、親のブラウジング・コンテキストでリンクを開くことになるでしょう。

  • CSS をサポートするユーザーエージェントの場合：ユーザーエージェントは、iframe 要素のネストされたブラウジング・コンテキストのアクティブド・キュメントのカスケードに、その iframe 要素に適用するスタイルシートすべてを加えなければいけません。適切なカスケード・レベルで、そのドキュメント自身によって指定されたどのスタイルシートよりも前に加えなければいけません。

  • CSS をサポートするユーザーエージェントの場合：ユーザーエージェントは、CSS プロパティ継承だけのために、iframe 要素のネストされたブラウジング・コンテキストのアクティブ・ドキュメントのルート要素を、そのiframe 要素の子であるとして扱わなければいけません。（ゆえに、iframe 要素内のドキュメントのルート要素の継承プロパティは、初期値を取る代わりに、iframe 要素上のそれらのプロパティのコンピューテッド値を継承するでしょう。）

  • CSS をサポートするユーザーエージェントがビジュアル・メディアで表示する場合：ユーザーエージェントは、iframe 要素の固有の幅を、'width: auto' を持った非置換のブロックレベル要素だったときに適用される幅に、セットするべきです。

  • CSS をサポートするユーザーエージェントがビジュアル・メディアで表示する場合：ユーザーエージェントは、現在の幅における iframe 要素でレンダリング（前の箇条書きの通り）されたコンテンツの周りのバウンディング・ボックスの高さに、iframe 要素の固有の高さをセットするべきです。それは、もし、そのスクロール位置が iframe 要素の中にレンダリングされたコンテンツに対する表示域のトップだったなら、そのコンテンツのカンバスのオリジンで調整されたかのようになるでしょう。

  • CSS をサポートするユーザーエージェントがビジュアル・メディアで表示する場合：ユーザーエージェントは、iframe 要素のネストされたブラウジング・コンテキストのアクティブ・ドキュメントの初期の包含ブロックの高さを強制的に 0 にしなければいけません。

    パーセンテージでサイズを指定すると、包含ブロックの高さに依存してしまいますが、ゆえに、ドキュメントのバウンディングボックスの高さに影響し、ゆえに、表示領域の高さに影響し、ゆえに、初期の包含ブロックのサイズに影響してしまいます。これは、その循環依存関係を回避することを目的としています。

  • スピーチメディアの場合、ユーザーエージェントは、ネストされたブラウジング・コンテキストを、それが分割されたドキュメントと読み上げずにレンダリングするべきです。

  • ユーザーエージェントは、一般的には、iframe 要素のネストされたブラウジング・コンテキストのアクティブ・ドキュメントが、その iframe 要素を組み込んでいるドキュメントの一部だったかのように動作するべきです。

    例えば、もしユーザーエージェントがドキュメント内のリンクすべてのリスティングをサポートするなら、 "シームレスに" ネストされたドキュメントの中にあるリンクは、そのドキュメント自身の中のリンクからとりわけ区別されることなしに、そのリストに含められるでしょう。

もしこの属性が指定されなかったら、または、先にリストしたオリジンの条件に一致するものがなければ、ユーザーエージェントは、ネストされたブラウジング・コンテキストを、分割したブラウジング・コンテキストとして明確に区別できるようにレンダリングするべきです。そして、シームレス・ブラウジング・コンテキスト・フラグはそのブラウジング・コンテキストに対して false にセットされなければいけません。

ユーザーエージェントは、iframe 要素のネストされたブラウジング・コンテキストのアクティブ・ドキュメントが変更されたらいつも前述の条件を再チェックする点は重要なポイントです。たとえば、ネストされたブラウジング・コンテキストが他のオリジンにナビゲートされると、シームレス・ブラウジング・コンテキストフラグは解除されます。

この属性は、動的にセットしたり削除することができ、それに連動して再レンダリングされます。

この例では、サイトのナビゲーションが、iframe 要素を使うクライアント側の組み込みを使って、組み込まれています。iframe 要素内のどのリンクも、新しいユーザーエージェントでは、iframe 要素の親のブラウジング・コンテキストで自動的に開かれるでしょう。古いユーザーエージェントに対応するために、このサイトに、target 属性が _parent という値となる base 要素を入れることもできます。同様に、新しいユーザーエージェントでは、親ページのスタイルは、そのフレームのコンテンツに自動的に適用されるでしょう。しかし、古いユーザーエージェントをサポートするために、ウェブ制作者は、明示的にスタイルを入れておきたいと思うかもしれません。

<nav><iframe seamless src="nav.include.html"></iframe></nav>

iframe 要素は、組込コンテンツが特定の寸法を持つ場合のためにディメンジョン属性をサポートします（例：広告ユニットが明瞭な寸法を持つ）。

iframe 要素は、決してフォールバック・コンテンツを持ちません。なぜなら、iframe 要素は、指定された初期コンテンツが成功裏に使われたかどうかにかかわらず、常に、ネストされたブラウジング・コンテキストを生成するからです。

iframe 要素の子孫は何も表しません。（iframe 要素をサポートしない古いユーザーエージェントでは、そのコンテンツは、フォールバックコンテンツとして動作することができるマークアップとしてパースされるでしょう。）

HTML ドキュメントで使うとき、iframe 要素に許されるコンテンツモデルはテキストです。ただし、context 要素に iframe 要素を、input にテキスト・コンテンツを引き渡して HTML フラグメント・パース・アルゴリズムを呼び出した結果が、すべてフレージング・コンテンツとなるノードのリストとなり、パース・エラーが発生せず、そのリストに、または、そのリストの要素の子孫に script 要素が一切なく、そして、そのリストのすべての要素（それらの子孫も含む）が、それら自身、準拠している場合は除きます。

iframe 要素は、XML ドキュメントでは、空でなければいけません。

HTMLパーサーは、iframe 要素内のマークアップをテキストとして扱います。

IDL 属性 src, srcdoc, name, sandbox, seamless は同じ名前の対応するコンテンツ属性を反映しなければいけません。

contentDocument IDL 属性は、iframe 要素のネストされたブラウジングコンテキストのアクティブ・ドキュメントの Document オブジェクトを返さなければいけません。

contentWindow IDL 属性は、iframe 要素のネストされたブラウジングコンテキストの WindowProxy オブジェクトを返さなければいけません。

この例では、iframe を使って、広告仲介業者からの広告をページに組み込んでいます：

<iframe src="http://ads.example.com/?customerid=923513721&amp;format=banner"
        width="468" height="60"></iframe>

※ 原文：http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#the-iframe-element