1. 導入

このセクションは規定です。

CSSは、ツリー状の要素（他の要素やテキストノードを混在して含むことができる）と、テキストノード（テキストを含むことができる）からなるソース文書を受け取り、画面、紙、オーディオストリームなどのキャンバス上に描画します。 このようなソース文書はCSSで描画可能ですが、最も一般的なのはDOM型です。[DOM]（より複雑なツリー型にはコメントノードなど追加のノード型が存在する場合もあります。 CSSの目的では、これら追加ノード型はすべて無視され、存在しないものとして扱われます。）

このために、CSSは中間構造として ボックスツリーを生成します。 これは描画された文書の整形構造を表します。 ボックスツリーの各ボックスは、それに対応する要素（または疑似要素）をキャンバス上の空間や時間で表現します。 また、ボックスツリー内の各テキストシーケンスは、対応するテキストノードの内容を表します。

ボックスツリーを作成するために、 CSSはまずカスケードと継承を使って、各CSSプロパティの算出値をソースツリー内の各要素やテキストノードに割り当てます。 （[CSS-CASCADE-3]参照。）

次に、各要素について、 CSSはその要素のdisplayプロパティで指定された通りに、0個以上のボックスを生成します。 通常、要素は1つのボックス（主ボックス）を生成し、これは自身を表し、ボックスツリー内に内容を持ちます。 ただし、一部のdisplay値 （例：display: list-item） では複数のボックス（例：主ブロックボックスと子マーカーボックス）が生成されます。 また、noneやcontentsのような値は、 要素やその子孫が一切ボックスを生成しません。 ボックスは、そのdisplay型で呼ばれることが多く、例えばboxがdisplay: blockで生成された場合、「ブロックボックス」または単に「ブロック」と呼ばれます。

ボックスには、生成元の要素と同じスタイルが割り当てられます（特記がない限り）。 一般的に、継承プロパティは主ボックスに割り当てられ、 その後ボックスツリー内で同一要素から生成された他のボックスへ継承されます。 非継承プロパティは通常主ボックスに適用されますが、複数ボックスが生成される場合は別ボックスに適用が定義されることもあります。 例えば、borderプロパティはtable要素の場合、テーブルグリッドボックスに適用され、 主テーブルラッパーボックスには適用されません。 値の計算処理がそれらのボックスのスタイルを変更し、要素のスタイルが要求された場合（例えばgetComputedStyle()など）、 要素には、各プロパティごとにそのプロパティが適用されたボックスの値が反映されます。

同様に、隣接するテキストノードの連続したシーケンスは、 それらのテキスト内容を含むテキストシーケンスを生成し、 生成元のテキストノードと同じスタイルが割り当てられます。 ただし、そのシーケンスにテキストが含まれない場合はテキストシーケンスは生成されません。

ボックスツリーを構築する際、 要素から生成されたボックスは祖先要素の主ボックスの子孫になります。 一般的には、要素の主ボックスの直接親ボックスは、最も近い祖先要素の主ボックスですが、例外もあります。 例として、run-inボックスや、複数のコンテナボックスを生成する表示型（テーブルなど）、介在する匿名ボックスなどです。

匿名ボックスは、いかなる要素にも紐付かないボックスです。匿名ボックスは、ボックスツリーが特定の入れ子構造を必要とする場合に、要素ツリーから生成されたボックスだけでは足りない場合に生成されます。 例えば、テーブルセルボックスには特定の親ボックス（テーブル行ボックス）が必要ですが、親がテーブル行ボックスでない場合は、自身の周囲に匿名テーブル行ボックスが生成されます。 （[CSS2] § 17.2.1参照。） 要素生成ボックスはスタイル継承が要素ツリーを通じて厳密に行われますが、 匿名ボックス（ボックスツリー内のみに存在）は、そのボックスツリーの親子関係で継承します。

レイアウトの過程で、ボックスやテキストシーケンスは複数のフラグメントに分割されることがあります。 例えば、インラインボックスやテキストシーケンスが行をまたいで分割される場合、 ブロックボックスがページやカラムをまたいで分割される場合（分断）、双方向テキストの再配列（双方向再配列アルゴリズムの適用や、CSS書字モード参照）、高レベルのdisplay型ボックス分割（例：ブロック内インライン分割（CSS2§9.2）、カラムスパンナー分割（CSS Multi-column Layout）など）です。 ボックスは1つ以上のボックスフラグメントからなり、 テキストシーケンスは1つ以上のテキストフラグメントからなります。 [CSS-BREAK-3]で分断の詳細を参照してください。

注: 多くのCSS仕様はこの用語体系が整理される前に書かれており、誤った参照がある場合もあるため、これらの用語を使っている古い仕様は注意して参照してください。文脈から本来の意味を推測可能なはずです。見つけた誤りは仕様ステータスで報告してください。修正されます。

注: 「オーラル」ボックスツリーとdisplayプロパティとの関係については、CSS Speech Module [CSS-SPEECH-1]も参照してください。

1.1. モジュールの相互作用

このモジュールは、displayプロパティの定義（[CSS2] §9.2.4）を置き換え、拡張します。

このモジュールのいずれのプロパティも::first-lineや::first-letter疑似要素には適用されません。

1.2. 値の定義

この仕様はCSSプロパティ定義の慣習（[CSS2]）および値定義構文（[CSS-VALUES-3]）に従います。 この仕様で定義されていない値型はCSS Values & Units [CSS-VALUES-3]で定義されています。 他のCSSモジュールとの組み合わせでこれらの値型の定義が拡張されることがあります。

各プロパティ定義に記載された固有値に加え、 この仕様で定義されるすべてのプロパティはCSS全体キーワードも値として受け付けます。 可読性のため、ここでは繰り返し明記していません。

2. ボックスレイアウトモード：displayプロパティ

ユーザーエージェントは、視覚以外も含め、すべてのメディアでこのプロパティをサポートすることが期待されています。 displayプロパティは要素のdisplay型を定義し、 これは要素がボックスを生成する2つの基本的な属性から成ります：

• 内側display型： （非置換要素の場合）生成する整形コンテキストを定義し、 子孫ボックスのレイアウト方法を決定します。 （置換要素の内側displayはCSSの範囲外です。）

• 外側display型： 主ボックス自身がフローレイアウトにどう参加するかを決定します。

テキストシーケンスにはdisplay型はありません。

一部のdisplay値は追加副作用があります。 例えばlist-itemは::marker疑似要素も生成し、 noneは要素のサブツリー全体をボックスツリーから除外します。

値の定義は以下の通り：

<display-outside>  = block | inline | run-in
<display-inside>   = flow | flow-root | table | flex | grid | ruby
<display-listitem> = <display-outside>? && [ flow | flow-root ]? && list-item
<display-internal> = table-row-group | table-header-group |
                     table-footer-group | table-row | table-cell |
                     table-column-group | table-column | table-caption |
                     ruby-base | ruby-text | ruby-base-container |
                     ruby-text-container
<display-box>      = contents | none
<display-legacy>   = inline-block | inline-table | inline-flex | inline-grid

次の参考表はdisplay値をまとめたものです：

注: 「最も後方互換、次に最短」優先ルールに従い、 同等なdisplay値のシリアライズは「短いdisplay」列を使います。[CSSOM]

2.1. フロー・レイアウトの外部表示ロール：block、inline、 およびrun-inキーワード

<display-outside>キーワードは、要素の外側display型（本質的にはその主ボックスがフロー・レイアウトにおいて果たす役割）を指定します。 定義は以下の通りです：

block

要素はフロー・レイアウトに配置されるとき、ブロックレベルのボックスを生成します。[CSS2]

inline

要素はフロー・レイアウトに配置されるとき、インラインレベルのボックスを生成します。[CSS2]

run-in

要素はrun-inボックスを生成します。これは特別な挙動を持つインラインレベルボックスで、後続のブロックコンテナに統合しようとします。 詳細は § 5 Run-Inレイアウト を参照してください。

注: 外側display型は置換要素にも影響します。

<display-outside>値が指定され、<display-inside>が省略された場合、 要素の内側display型はflowがデフォルトになります。

2.2. 内部表示レイアウトモデル：flow、flow-root、table、flex、grid、およびrubyキーワード

<display-inside>キーワードは、要素の内側display型を指定します。 これは、その内容をレイアウトする整形コンテキストの種類を定義します（非置換要素の場合）。 定義は以下の通りです：

flow

要素はフロー・レイアウト（ブロック・インラインレイアウト）を使って内容をレイアウトします。

その外側display型がinlineやrun-inの場合、かつブロックまたはインライン整形コンテキストに参加している場合は、インラインボックスを生成します。

それ以外の場合はブロックコンテナボックスを生成します。

他のプロパティ（position、float、overflowなど）や、要素自身がブロックまたはインライン整形コンテキストに参加しているかどうかによって、 自身の内容に新しいブロック整形コンテキストを確立するか、親の整形コンテキストに内容を統合します。 CSS2.1 第9章参照。[CSS2] 新しいブロック整形コンテキストを確立するブロックコンテナは、使用される内側display型がflow-rootであるとみなされます。

flow-root

要素はブロックコンテナボックスを生成し、 内容はフロー・レイアウトでレイアウトされます。 常に内容に新しいブロック整形コンテキストを確立します。[CSS2]

table

要素は主となるテーブルラッパーボックスを生成し、ブロック整形コンテキストを確立します。 さらにテーブルグリッドボックスも生成し、テーブル整形コンテキストを確立します。[CSS2]

flex

要素は主となるフレックスコンテナボックスを生成し、 フレックス整形コンテキストを確立します。[CSS-FLEXBOX-1]

grid

要素は主となるグリッドコンテナボックスを生成し、 グリッド整形コンテキストを確立します。[CSS-GRID-1]

（subgridを使うグリッドは、必ずしも新しいグリッド整形コンテキストを生成しない場合があります。 詳細は[CSS-GRID-2]参照。）

ruby

要素はルビコンテナボックスを生成し、 ルビ整形コンテキストを確立します。 また、ベースレベルの内容を親の整形コンテキストに統合（インラインの場合）するか、非インラインの場合は適切な外側display型のラッパーボックスを生成します。[CSS-RUBY-1]

<display-inside>値が指定され、<display-outside>が省略された場合、 要素の外側display型はblockがデフォルトです。ただしrubyはinlineがデフォルトになります。

2.3. マーカーボックスの生成：list-item キーワード

list-itemキーワードは、 要素に::marker疑似要素[CSS-PSEUDO-4]（list-styleプロパティで内容指定）を生成し、 さらに自身の内容用の指定型の主ボックスも生成します。 （CSS 2.1§12.5 リスト）[CSS2]

内側display型が指定されない場合、主ボックスの内側display型はflowがデフォルトです。 外側display型が指定されない場合、主ボックスの外側display型はblockがデフォルトです。

注: このレベルでは文法が制限されているため、 list-itemはフロー・レイアウト型 （block／inline／run-in＋flow／flow-root内側型）に限定されています。 この制限は将来のモジュールレベルで緩和される可能性があります。

2.4. レイアウト内部表示型：table-*およびruby-*キーワード

一部のレイアウトモデル（tableやrubyなど）は、複雑な内部構造を持ち、 子や子孫が果たす役割が複数あります。 このセクションでは、そうした「レイアウト内部」display値を定義します。 これらは特定のレイアウトモード内でのみ意味を持ちます。

特に定めがない限り、 これらdisplay値を使う要素の内側display型と外側display型は、そのキーワードに設定されます。

displayプロパティが置換要素でレイアウト内部値に算出される場合、 実際はinlineとして扱われます。 空白折り畳みや匿名ボックス生成は、そうした置換要素の周囲でinline値に基づいて行われ、 レイアウト内部display値が適用されていないかのように扱われます。

作者はレイアウト内部display値を置換要素に指定すべきではありません。

<display-internal> キーワードは以下の通り定義されています：

table-row-group, table-header-group, table-footer-group, table-row, table-cell, table-column-group, table-column

要素は内部テーブル要素となります。 適切な内部テーブルボックスを生成し、テーブル整形コンテキストに参加します。 CSS2§17.2 [CSS2]参照。

table-cellボックスはflow-rootの内側display型を持ちます。

table-caption

要素はテーブルキャプションボックスを生成します。 これはブロックボックスで、テーブルやテーブルラッパーボックスに関して特別な挙動を持ちます。 CSS2§17.2 [CSS2]参照。

table-captionボックスはflow-rootの内側display型を持ちます。

ruby-base, ruby-text, ruby-base-container, ruby-text-container

要素は内部ルビ要素となります。 適切な内部ルビボックスを生成し、ルビ整形コンテキストに参加します。[CSS-RUBY-1]

ruby-baseとruby-textはflowの内側display型を持ちます。

レイアウト内部display型を持つボックスは、親が不適切な場合、仕様に従い自身の周囲に匿名ラッパーボックスを生成します。

<div style="display:block;">
  <div style="display:table-cell">...</div>
</div>

block box
└anonymous table box
 └anonymous table-row-group box
  └anonymous table-row box
   └table-cell box

<div style="display:table;">
  <div style="display:table-row">
    <div style="display:table-cell">...</div>
  </div>
</div>

table box
└anonymous table-row-group box
 └table-row box
  └table-cell box

2.5. ボックス生成：noneおよびcontentsキーワード

displayは要素が生成するボックスの種類を制御できるだけでなく、 要素がそもそもボックスを生成するかどうかも制御できます。

<display-box>キーワードは以下のように定義されます：

contents

要素自体はボックスを生成しませんが、子や疑似要素は通常通りボックスやテキストシーケンスを生成します。 ボックス生成とレイアウトに関しては、この要素は要素ツリー内で内容（ソース文書の子要素や疑似要素を含む）に置き換えられたものとして扱われます。 （例えば::beforeや::after疑似要素は、通常通り要素の子の前後に生成されます。）

注: 影響を受けるのはボックスツリーのみであり、セレクターマッチ・イベントハンドリング・プロパティの継承など文書ツリーに基づく意味論には影響しません。ただし現時点では、主なブラウザで正しく実装されていませんので、この機能のWebでの利用は注意が必要です。アクセシビリティツールが要素の意味論にアクセスできなくなる可能性があります。

この値は置換要素やCSS以外でレンダリングが完全に制御されない要素ではdisplay: noneに算出されます。 詳細は付録B：display: contentsが特殊要素に与える影響を参照してください。

注: 置換要素やフォームコントロールは特別扱いされます。要素自身のボックスの生成だけを取り除く操作は曖昧なためです。 利用例やレンダリングモデルが発展した場合、この動作が精緻化される可能性があるため、将来互換性の観点からこのような要素にはdisplay: contentsではなくdisplay: noneを使うべきです。

none

要素およびその子孫はボックスやテキストシーケンスを一切生成しません。

同様に、テキストノードがdisplay: noneとして扱われる場合、テキストシーケンスを生成しません。

これらの値が設定された要素は内側や外側display型を持ちません。なぜなら、全くボックスを生成しないためです。

注: これらの値は対象要素がボックスを生成しなくなるため、匿名ボックス生成規則も除外された要素を完全に無視し、ボックスツリー上に存在しないものとして扱います。

ただし、マークアップベースの関係性には影響しません。これはレンダリング時のみの効果です。例えば、どのテーブルセルが列に表示されるかには影響しますが、どのテーブルセルが特定の列要素に紐付くかには影響しません。同様に、HTMLの summary 要素が特定のテーブルに紐付くかや、 legend が特定の fieldset の内容のラベルとみなされるかには影響しません。

2.6. 事前合成インラインレベルdisplay値

CSSレベル2ではdisplayに単一キーワード構文を使用しており、同じレイアウトモードのブロックレベル・インラインレベルのバリアントで別のキーワードが必要でした。 これらの<display-legacy>キーワードは以下のように対応します：

inline-block

inline flow-rootに算出されます。

inline-table

inline tableに算出されます。

inline-flex

inline flexに算出されます。

inline-grid

inline gridに算出されます。

注: これらのキーワードとその同等値は算出値としては同じですが、指定値は区別されます。

注: getComputedStyle() のシリアライズ規則では、後方互換性と最短原則のため、常にこれら事前合成キーワードが出力され、同等の2キーワードペアでは出力されません。

2.7. ボックスタイプの自動変換

一部のレイアウト効果では、ボックスタイプのブロック化やインライン化が必要となり、 ボックスの算出外側display型がblockやinlineに設定されます。 （これはdisplay型が全くボックスを生成しない場合、すなわちnoneやcontentsには影響しません。） また、以下のような挙動があります：

• ブロックボックス（block flow）がインライン化される場合、 内側display型がflow-rootに設定され、ブロックコンテナであり続けます。

• インラインボックス（inline flow）がインライン化される場合、 インフローの子要素を再帰的にインライン化し、ブロックレベルの子孫によってインライン整形コンテキストが分断されないようにします。

• レガシー理由により、インラインブロックボックス （inline flow-root）がブロック化される場合、 blockボックスになり（flow-root性を失う）。 一貫性のため、run-in flow-rootボックスもブロック化されてblockボックスになります。

• レイアウト内部ボックスがブロック化された場合、 内側display型がflowに変換され、ブロックコンテナになります。インライン化はレイアウト内部ボックスには影響しません。 （ただし、インラインコンテキストに配置された場合は、適切な型の匿名インラインレベルボックスでラップされます。）

注: コンテキストに合わないボックス型を修正する方法は2つあります。 一つは、ここで説明する算出値のdisplayの変換（ブロック化・インライン化）。 もう一つは、ボックスツリー構築（算出値決定後）で中間的な匿名ボックスを生成すること。 これはテーブル、ルビ、 フローレイアウトなどで起こります。

2.8. ルート要素の主ボックス

ルート要素のdisplay型は常にブロック化され、 その主ボックスは必ず独立した整形コンテキストを確立します。 このボックスの包含ブロックは初期包含ブロックです。

さらに、ルート要素のdisplayがcontentsの場合は、算出値としてblockになります。

3. 表示順序：orderプロパティ

ボックスは通常、ソース文書の順序どおりに表示・レイアウトされます。 ただし一部の整形コンテキストでは、 orderプロパティによってボックスの順序を変更でき、 要素の論理的な順序と2次元画面上の空間配置の順序を意図的にずらすことができます。 （§ 3.1 並べ替えとアクセシビリティ参照。）

具体的には、 orderプロパティは、フレックスアイテムやグリッドアイテムがコンテナ内で現れる順序を制御し、 それらを順序グループに割り当てます。 値は一つの<integer>であり、 各アイテムが属する順序グループを指定します。

例えばカタログ商品カードの例です。 タイトル、写真、説明があります。 各エントリ内では、ソース文書の内容はタイトル→説明→写真の順で論理的に配置されます。 これは音声レンダリングやCSS未対応ブラウザで合理的な順序になります。 しかし、より魅力的な視覚的配置のために、orderで画像を内容の後方からカードの上部に引き上げています。

article.sale-item {
  display: flex;
  flex-flow: column;
}
article.sale-item > img {
  order: -1; /* 画像を他の内容より前に（レイアウト順で）移動 */
  align-self: center;
}

<article class="sale-item">
  <h1>コンピュータ スターターキット</h1>
  <p>これは予算が少ない場合に最適なコンピュータです。
  <ul>
    <li>コンピュータ
    <li>モニター
    <li>キーボード
    <li>マウス
  </ul>
  <img src="images/computer.jpg"
    alt="内容: ホワイトのデスクトップコンピュータと周辺機器一式。">
</article>

コンピュータ スターターキット

これは予算が少ない場合に最適なコンピュータです。

• コンピュータ
• モニター
• キーボード
• マウス

フレックスおよびグリッドコンテナは 内容をorder修正済み文書順でレイアウトします。 最も小さい順序グループから高い順へ並べます。 同じ順序グループはソース文書の出現順でレイアウトされます。 これはペイント順にも影響します[CSS2]。 ちょうどフレックス／グリッドアイテムがソース文書で順序変更された場合と同様です。 フレックス／グリッドコンテナ内の絶対配置の子要素は、order: 0として扱われ、フレックス/グリッドアイテムとの相対ペイント順を決定します。

将来の仕様で別途定められない限り、 このプロパティはフレックスアイテムやグリッドアイテム以外のボックスには影響しません。

3.1. 並べ替えとアクセシビリティ

orderプロパティは、非視覚メディア（音声など）での順序には影響しません。 また、orderは 逐次ナビゲーション（リンク巡回など、例えばtabindex [HTML]）の既定の巡回順にも影響しません。

作者は、orderを論理順序ではなく、空間順序の変更だけに使う必要があります。 orderによる論理並べ替えを行うスタイルシートは非適合です。

注: 非視覚メディアやCSS未対応UAは通常内容を直線的に提示するため、 論理的なソース順に依存できます。一方、orderはレイアウト順の調整に使います。 （視覚認知は2次元・非線形なので、希望するレイアウト順が論理順でない場合もあります。）

著者の意図した順序をすべての表示モードで維持するため、 オーサリングツール（WYSIWYGエディタやWebベースの補助ツールなど）は、下層文書ソース自体を並べ替え、 orderだけで並べ替えを行ってはなりません。 ただし、著者が空間順序だけを非同期にしたいと明示した場合（音声順やナビ順は文書順に従うべき場合）は除きます。

注: ブラウザ、支援技術、拡張機能などのUAは空間ナビゲーション機能を提供する場合があります。 このセクションは、そうした空間ナビで要素順を決める際にorderプロパティの尊重を妨げません。 実際、そうした機能にはorderも考慮される必要があります。 ただしorderは空間ナビ機能で考慮すべき唯一（主）CSSプロパティではありません。 実装の良い空間ナビ機能は、空間関係に影響するCSSのすべてのレイアウト機能を考慮する必要があります。

4. 不可視性：visibilityプロパティ

visibilityプロパティはボックスが表示されるかを指定します。不可視ボックスもレイアウトには影響します。 （完全にボックス生成を抑制したい場合はdisplayプロパティをnoneに設定してください。） 値の意味は以下のとおりです：

visible

生成されたボックスは通常どおり表示されます。

hidden

要素が生成するすべてのボックスは不可視になります。 ただし、子孫要素がvisibility: visibleを持つ場合は表示されることもあります。

collapse

ボックスが折り畳まれた状態であることを示し、 整形コンテキストごとに通常より小さい領域になる場合があります。 詳細はテーブルの動的行・列効果 [CSS2]や フレックスレイアウトにおける折り畳みフレックスアイテム [CSS-FLEXBOX-1]を参照。 その他の場合（特記なき場合）は、単に不可視になり、hiddenと同様です。

注: 現状多くのUAやアクセシビリティツールは、 不可視要素と意味的関係を持つ表示要素のアクセシビリティを正しく実装できていません。 例えば特別な役割（テーブル行など）の親要素を不可視にしつつ、特別な役割（テーブルセルなど）の子要素は表示する場合、 そうしたツール利用者は問題が生じることがあります。 作者はツール状況が改善するまで、これらの状況を避けるべきです。

不可視ボックスは表示されません（完全に透明であるかのように扱われます）、操作できません （pointer-events: noneと同様に振る舞います）、 ナビゲーションから除外されます （display: noneと同様）、 音声へのレンダリングもされません （ただしspeakがalwaysの場合を除く [CSS-SPEECH-1]）。 ただしdisplay: contents同様、 コンテナとしての意味的役割は失われず、visibleな子孫を正しく解釈できるようになっています。

注: speakがalwaysの場合、 不可視ボックスも音声でレンダリングされ、 非視覚・空間的手段で操作可能です。

<p>映画の前半の象徴性は、最後に明らかになることで
  <spoiler-text><span>ルークが自分の父であること</span></spoiler-text>が判明し、
  魔法使いの謎めいた言葉が意味を持つようになる。
<style>
spoiler-text { border-bottom: 1px solid; }
spoiler-text > span { visibility: hidden; }
spoiler-text.shown > span { visibility: visible; }
</style>
<script>
[...document.querySelectorAll("spoiler-text")].forEach(el=>{
  el.addEventListener("click", e=>el.classList.toggle("shown"));
});
</script>

5. ランインレイアウト

ランインボックスは、直後にくるブロックに統合されるボックスであり、そのブロックのインラインレベル内容の先頭に自身を挿入します。 これは、コンパクトな見出しや定義などを整形する際に便利です。適切なDOM構造としては、見出しが後続の文章の前に置かれますが、希望する表示はインライン見出しがテキストと並んでレイアウトされることです。

<dl class='dict'>
  <dt>dictionary
  <dd>a book that lists the words of a language in alphabetical
      order and gives their meaning, or that gives the equivalent
      words in a different language.
  <dt>glossary
  <dd>an alphabetical list of terms or words found in or relating
      to a specific subject, text, or dialect, with explanations; a
      brief dictionary.
</dl>
<style>
.dict > dt {
  display: run-in;
}
.dict > dt::after {
  content: ": "
}
</style>

dictionary: a book that lists the words of a language
in alphabetical order and explains their meaning.

glossary: an alphabetical list of terms or words found
in or relating to a specific subject, text, or dialect,
with explanations; a brief dictionary.

ランインボックスは他のインラインレベルボックスと全く同じように振る舞いますが、以下の点が異なります：

• ランインボックスがflowの内側display型を持つ場合、その内容をインライン化します。
• ランインシーケンスの直後に新しいブロック整形コンテキストを確立しないブロックボックスが続く場合、そのシーケンスはそのブロックボックスの直接の子として挿入されます：::marker疑似要素のボックス（存在する場合）の後、かつそのブロックの内容によって生成される他のボックス（::before疑似要素によるボックスを含む、存在する場合）の前。 この再親化は可能なら再帰的に行われ（ランインが実質的に後続の最も深い「段落」の一部となり、隣接する新しいランインも集めていく）、再親化された内容は、元々そこに親化されていたかのように整形されます。注：影響を受けるのはレイアウトのみであり、継承には影響しません。非匿名ボックスのプロパティ継承は要素ツリーのみを基準とするためです。
• それ以外の場合（ランインシーケンスの直後にそのようなブロックが続かない場合）、そのランインシーケンスと、直後に続くインラインレベル内容（次のランインシーケンスまで、存在する場合は除く）を囲む匿名ブロックボックスが生成されます。

ランインシーケンスは、連続した兄弟ランインボックスとその間の空白およびアウトオブフローボックスの最大連続列です。

注: この記述は、アウトオブフローボックスが2つのランインボックスの間にある場合は再親化されることを意味します。 別案としては、間のアウトオブフローボックスを残す、あるいはアウトオブフローボックスが前方のランインの統合を妨げるようにすることも考えられます。 実装者や作者は希望する挙動があればCSSWGに連絡してください。現在の仕様は多少ランダムに選ばれたものです。

この修正は、CSS2§9.2で記述されている匿名ブロック・インラインボックス修正の前に行われ、影響を受ける要素の最初の整形行の決定に影響します。まるでランインシーケンスが元々ボックスツリーの最終位置にあったかのように扱われます。

注: 最も早いランインは、含まれるブロックの最初の整形行の最初のテキストを表します。 したがって、そのブロック要素に::first-letter疑似要素が適用された場合、ランインの最初の文字が選択され、そのブロック自身の内容の最初の文字ではありません。

注: このランインモデルは、[CSS2]の初期案で提案されたものとは若干異なります。

付録A：用語集

以下の用語は便宜のためここで定義します：

ルート要素

要素のうち、文書ツリーの根となるもの。 DOMによって生成された文書ツリーの場合は、文書要素です。HTMLの場合は html 要素となります。[DOM] [HTML]

主ボックス

要素が1つ以上のボックスを生成する場合、 そのうち1つが主ボックスであり、 子孫ボックスや生成内容を含み、位置決めの対象にもなります。

一部の要素は主ボックスの他にも追加ボックスを生成する場合があります。例えばlist-item要素は追加のマーカーボックスを生成し、table要素は主テーブルラッパーボックスと追加のテーブルグリッドボックスを生成します。 これら追加ボックスは主ボックスを基準に配置されます。

インラインレベル

インラインレイアウトに参加する内容。具体的にはインラインレベルボックスやテキストシーケンス。

ブロックレベル

ブロックレイアウトに参加する内容。具体的にはブロックレベルボックス。

インラインボックス

非置換のインラインレベルボックスで、その内側display型がflowであるもの。 インラインボックスの内容は自身と同じインライン整形コンテキストに参加します。

inline

文脈が明確な場合、インラインボックスやインラインレベルボックスの略称。また形容詞としてインラインレベルを意味することもあるが、後者の使い方は非推奨。

アトミックインライン

画像など置換されるインラインレベルボックスや、inline-blockやinline-tableなど新たな整形コンテキストを確立し、行分割できないボックス。

内側display型がflowでないインラインレベルボックスは、その型で新しい整形コンテキストを確立します。

ブロックコンテナ

ブロックコンテナは、インライン整形コンテキストに参加するインラインレベルボックスのみ、またはブロック整形コンテキストに参加するブロックレベルボックスのみを含みます（この制約を守るため、匿名ブロックボックスを生成することもあります。詳細はCSS2§9.2.1.1参照）。

インラインレベル内容のみ含む場合、新しいインライン整形コンテキストを確立します。 要素はさらに、そのインライン内容をすべてラップするルートインラインボックスも生成します。注：このルートインラインボックスの概念は、CSS2§9.2.2.1で導入された「匿名インライン要素」概念の実質的な代替です。

親の整形コンテキストがブロック整形コンテキストでない場合、ブロックコンテナは新しいブロック整形コンテキストを確立します。 そうでない場合は、自身がブロック整形コンテキストに参加している際、内容のために新しいブロック整形コンテキストを確立するか、参加しているものを継続するかは、他のプロパティ（overflowやalign-contentなど）の制約によって決まります。

注: ブロックコンテナボックスは、ブロック整形コンテキストとインライン整形コンテキストの両方を同時に確立できる場合があります。

ブロックボックス

ブロックレベルボックスかつブロックコンテナであるもの。

注: すべてのブロックコンテナボックスがブロックレベルボックスとは限りません。例えば非置換インラインブロックや非置換テーブルセルはブロックコンテナですがブロックレベルボックスではありません。同様に、すべてのブロックレベルボックスがブロックコンテナとも限りません。ブロックレベル置換要素（display: block）やフレックスコンテナ（display: flex）などはブロックコンテナではありません。

ブロック

文脈が明確な場合、ブロックボックス、ブロックレベルボックス、ブロックコンテナボックスの略称。

置換要素

内容がCSS整形モデルの範囲外にある要素（画像や埋め込み文書など）。例えばHTMLの img 要素は、しばしばsrc属性で指定された画像に内容が置換されます。

置換要素はしばしば自然寸法を持ちます。 例えばビットマップ画像は絶対単位で自然幅・自然高さが指定されており、自然比率も明確です。 一方で他のオブジェクトは自然寸法を持たない場合もあります（例：空のHTML文書）。 詳細は[css-images-3]参照。

UAは、第三者に機密情報が漏れる可能性がある場合、置換要素に自然寸法がないものとして扱う場合があります。 例えばユーザーの銀行残高によってHTML文書の自然サイズが変わる場合、UAはそのリソースに自然寸法がないことにするかもしれません。

置換要素の内容はCSS整形モデルでは考慮されませんが、自然寸法はレイアウト計算に使われます。 置換要素は常に独立した整形コンテキストを確立します。

非置換要素は、置換でない、すなわちレンダリングがCSSモデルで決定される要素です。

包含ブロック

関連するボックスのサイズや位置決めの基準となる矩形。 特に、包含ブロックはボックスではありません（矩形です）が、しばしばボックスの寸法から導かれます。 各ボックスは自身の包含ブロックに対して位置が与えられますが、この包含ブロックに制限されません。オーバーフローすることもできます。 「ボックスの包含ブロック」とは「そのボックスが属する包含ブロック」を指し、自身が生成するものではありません。

一般的に、エッジがボックスの子孫ボックスの包含ブロックになります。ボックスが子孫の包含ブロックを「確立する」といいます。 包含ブロックのプロパティを参照する場合、ボックスが生成した包含ブロックの値を参照します。 （初期包含ブロックの場合は、特記がない限りルート要素の値を使います。）

詳細は[CSS2] 9.1.2節、10.1節、CSS Positioned Layout 3 § 2.1 Positioned Boxesの包含ブロック参照。

包含ブロックチェーン

連続する包含ブロックの祖先―子孫チェーン。 例えばインラインボックスの包含ブロックは最も近いブロックコンテナ祖先の内容ボックス。 そのブロックコンテナがインフローブロックなら、さらにその親ブロックコンテナが包含ブロックとなる。 祖父ブロックコンテナが絶対配置されている場合は、最も近いpositioned祖先のパディングエッジが包含ブロックになるなど、最終的には初期包含ブロックまで続きます。

初期包含ブロック

ルート要素の包含ブロック。 初期包含ブロックはブロック整形コンテキストを確立します。 位置や寸法については、CSS2.1§10.1（連続メディア）、[CSS-PAGE-3]（ページメディア）参照。

整形コンテキスト

整形コンテキストは、関連するボックス群がレイアウトされる環境です。 整形コンテキストの種類によってボックスのレイアウト規則が異なります。 例えばフレックス整形コンテキストはフレックスレイアウト規則で、ブロック整形コンテキストはブロック・インラインレイアウト規則でボックスを配置します。[CSS2] また一部の整形コンテキストは相互に重複・共存します。例えばインライン整形コンテキストは、親のブロック整形コンテキスト内に存在し、相互作用します。ルビコンテナは、ルビ整形コンテキストをそのベースコンテナのインライン整形コンテキスト上に重ねます。

ボックスは新しい独立した整形コンテキストを確立するか、親の整形コンテキストを継続するかのどちらかです。場合によっては新しい（非独立）共存整形コンテキストも確立しますが、特記なき限り新しい整形コンテキストは独立したものとなります。ボックスが確立する整形コンテキストの種類は、その内側display型によって決まります。例えばグリッドコンテナは新しいグリッド整形コンテキストを、ルビコンテナは新しいルビ整形コンテキストを、ブロックコンテナは新しいブロック整形コンテキストや新しいインライン整形コンテキストを確立できます。 詳細はdisplayプロパティを参照。

独立した整形コンテキスト

ボックスが独立した整形コンテキストを確立すると（その整形コンテキストが親と同じ型でも異なる型でも）、実質的に新しい独立したレイアウト環境を作ります。自身のボックスのサイズ以外は、子孫のレイアウトは（通常）外部の整形コンテキストの規則や内容には影響されず、逆も同様です。

例えば、ブロック整形コンテキストでは、floatしたボックスが周囲のボックスのレイアウトに影響しますが、その影響は自身の整形コンテキスト内だけに限定され、外部のfloatはそのボックスに侵入できません。

別例として、マージンは整形コンテキスト境界をまたいで折り畳まれません。

除外（exclusion）は、独立した整形コンテキスト境界を越えて内容に影響を与えられます（現時点では唯一のレイアウト機能）。[CSS3-EXCLUSIONS]

一部のプロパティは、本来なら確立しない場合でも独立した整形コンテキストを確立することを強制できます。 例えば、ボックスをアウトオブフローにすると、ブロック化とともに独立した整形コンテキスト確立も行われます。 また、containプロパティの一部値も独立した整形コンテキスト確立を引き起こします。 ブロックをスクロールコンテナにする場合も独立した整形コンテキスト確立となりますが、サブグリッドをスクロールコンテナにする場合はそうならず、親のグリッドコンテナのレイアウトに参加し続けます。

ブロックボックスが独立した整形コンテキストを確立すると、内容のために新しいブロック整形コンテキストを確立します。 ほかのほとんどのケースでは、独立した整形コンテキスト確立は無意味です。すでに独立した整形コンテキストを確立している（例：フレックスコンテナ）、あるいはその型のボックスでは完全な独立新整形コンテキストを確立できない（例：非置換インラインボックス）などです。

ブロック整形コンテキスト

インライン整形コンテキスト

ブロックとインライン整形コンテキストの定義はCSS 2.1 第9.4節参照。インライン整形コンテキストは、親のブロック整形コンテキスト内に存在（これに属する）します。例えば、インライン整形コンテキストに属する行ボックスは、ブロック整形コンテキストに属するfloatと相互作用します。

ブロックレイアウト

ブロックレベルボックスのレイアウトで、ブロック整形コンテキスト内で行われます。

ブロック整形コンテキストの根

ブロックコンテナで、新しいブロック整形コンテキストを確立するもの。

BFC

ブロック整形コンテキストやブロック整形コンテキストの根の略語。非公式には、内部floatを含み、外部floatを除外し、マージン折り畳みを抑制するボックス群などを指し、具体的には以下のいずれかを意味します：

• 内容のために新しいブロック整形コンテキストを確立するブロックコンテナ

• 内容のためにブロック整形コンテキストを確立するブロックボックス（つまり、ブロックレベルブロックコンテナ）（確立しないブロックボックスとは区別）

• （かなり広義には）新しい整形コンテキスト（インライン整形コンテキスト以外）を確立する任意のブロックレベルボックス

アウトオブフロー

インフロー

ボックスがアウトオブフローであるとは、期待される位置や周囲の内容との相互作用から切り離され、親の整形コンテキストの通常のフロー外で別のパラダイムでレイアウトされることです。float（float）や絶対配置（position）で発生します。 インフローとは、アウトオブフローでないことです。

注: 一部の整形コンテキストはfloatを抑制するため、float: leftが必ずしもアウトオブフローとは限りません。

文書順

ボックスや内容が文書で出現する順序（レンダリング順と異なる場合もある）。疑似要素の相対順序決定にはボックスツリー順を使います。詳細はCSS Pseudo-Elements 4 § 4 ツリーに従う疑似要素参照。

これら用語の詳細は[CSS2] 第9章参照。

付録B：display: contentsが特殊な要素に与える影響

このセクションは（現在）非規定です。

一部の要素はCSSボックスの概念だけで描画されるわけではありません。 例えば置換要素（ imgなど）、 多くのフォームコントロール（ inputなど）、 そしてSVG要素です。

この付録はそれらがdisplay: contentsとどう相互作用するかを定義します。

HTML要素

br

wbr

meter

progress

canvas

embed

object

audio

iframe

img

video

frame

frameset

input

textarea

select

display: contentsはdisplay: noneに算出されます。

legend

HTMLの仕様により、 legend にdisplay: contentsを指定した場合は描画されるlegendとはならず、魔法のような表示挙動はありません。 （したがって、display: contentsには通常通り反応します。）

button

details

fieldset

これらの要素は特別な挙動を持ちません。display: contentsは単にその主ボックスを除去し、内容は通常通り描画されます。

その他のHTML要素

display: contentsは通常通り動作します。

SVG要素

svg 要素（CSSボックスレイアウトがあるもの。HTML要素の子や文書ルート要素を含む）

display: contentsはdisplay: noneに算出されます。

その他のSVG コンテナ要素で、かつ描画可能要素であるもの

SVG テキスト内容子要素

use

display: contentsはその要素を整形ツリーから除去し、内容（shadow-DOM内容を含む）をその場所に持ち上げて表示します。

その他のSVG要素

display: contentsはdisplay: noneに算出されます。

要素が整形ツリーから除去された場合、その要素に設定されているレイアウトや視覚整形を制御するSVG属性は内容の描画時に無視されます。 ただし、SVGの提示属性（CSSプロパティにマッピングされるもの）は値処理や継承に引き続き影響します [CSS-CASCADE-3]。 したがって、そのような属性は子孫要素のプロパティ値に影響し、レイアウトや視覚整形に作用します。

MathML要素

すべてのMathML要素は、display: contentsがdisplay: noneに算出されます。

付録C：仕様著者向けボックス構築ガイドライン

このセクションは仕様著者向けの非規定ガイダンスです。

• ボックスはブロック化とインライン化を同時にできません。もし両方が発生するなら、どちらが優先か定義してください。

• 主ボックスでも匿名ボックスでもないボックスはブロック化できません。 ブロック化は要素の算出値に影響し、主ボックスの型を決定します。

• 内容をブロック化するボックスは、インラインレベル内容を直接含めません。 そのような要素内で生成されるボックスやテキストシーケンスはすべてブロック化するか、匿名のブロックコンテナでラップしてください。

• 内容をインライン化するボックスは、ブロックレベルボックスを直接含めません。 そのような要素内で生成されるボックスはインラインレベルでなければなりません。

• 本質的に独立した整形コンテキストを確立できない（非置換インラインなど）ボックスは、独立した整形コンテキスト確立を要求してはなりません。 まずブロック化するか、またはボックスタイプを確立可能なものに変更してください。

謝辞

長年にわたりボックス生成のバラバラな詳細を分離しようと尽力した多くの方々、特にBert Bos氏（display-modelとdisplay-roleによる最後の試みは実現しなかったものの、現仕様への準備となりました）、CSS2.1第9章の混乱に秩序をもたらしたAnton Prowse氏、そして本仕様の細かな違いと誤りを数多く解きほぐしてくれたOriol Brufau氏に感謝します。 また、David Baron氏、Mats Palmgren氏、Ilya Streltsyn氏、Boris Zbarsky氏にもフィードバック面で感謝します。

変更履歴

2020年候補勧告以降の変更点

2020年5月19日候補勧告以降のコメント処理状況があります。

2020年5月19日候補勧告以降の主な変更点：

• “text run”を“text sequence”に改称。 (Issue 7768)
• ルート要素の定義とそのレイアウトをブロックレベルとして、§ 2.8 ルート要素の主ボックス及び初期包含ブロックの定義で明確化。 (PR 8095, Issue 7207, Issue 6480, Issue 7786)
• orderプロパティの定義を[CSS-FLEXBOX-1]から移入（グリッドアイテムにも適用されるため）。 (Issue 5865)
• visibilityプロパティ定義を[CSS2]から取り込み、より網羅的かつ詳細に更新。 (Issue 6123)
• 置換要素がレイアウト内部display値の場合はdisplay: inlineとして扱うことを定義。 (Issue 6000)
• <display-legacy>値が、2キーワード同等値と実際に算出されることを明確化。 (Issue 5575)

  inline-…

  従来の挙動 算出値 inline …。

  注: これらキーワードと同等値は算出値として同じですが、指定値は区別されます。

  注: getComputedStyle() のシリアライズ規則では、事前合成キーワードが常に出力され、同等の2キーワードペアは出力されません（最短・後方互換原則による）。

• ブロック化やインライン化が算出値の変更であることを明確化。 (Issue 6251)

  一部のレイアウト効果では、ボックスタイプのブロック化やインライン化が必要になり、 そのボックスの 算出値 外側display型がblockやinline（それぞれ）に設定されます。

• 用語集にブロックレイアウトの定義追加。
• CSS Grid Layoutへの参照を更新。
• 細かな編集上の明確化・クロスリンク改善など。

2019年候補勧告以降の変更点

2019年7月11日候補勧告以降の変更点：

• 包含ブロックの定義に、[CSS2]から追加説明文を統合。
• CSSの目的上、要素やテキスト以外のDOMノードは無視されることを明確化。

  （一部のソース文書は、DOMのようなより複雑なツリーから始まり、コメントノードや他の型を持つ場合があります。 CSSの目的では、これら追加型ノードはすべて無視され、存在しないものとして扱われます。）

• 絶対配置関連の用語集定義を改善・移動。

2018年8月28日候補勧告以降の変更点：

• ボックスツリーの親子関係を定義。親ボックス参照。
• 絶対配置の定義を用語集に追加。参照しやすいようCSS2からコピー。
• § 1 導入で各種フラグメント化へのクロスリファレンス追加。
• “table box”を“table grid box”に名称変更し、“table wrapper box”との区別を容易化。
• ルート → 初期包含ブロック伝播に「特記なき場合」を追加。HTML body要素の特例に対応。

候補勧告以前の変更点

コメント処理状況あり。

2018年4月20日作業草案以降の変更点：

• display: contentsとして振る舞う要素がdisplay: noneとなり、算出値もdisplay: none。(Issue 2755)
• “新しい”整形コンテキストと独立した整形コンテキストを区別（特定の整形コンテキストがレイヤーするため）。 (Issue 2597, Issue 1457)
• ブロックボックスが独立した整形コンテキストを確立する場合、使用されるdisplayはflow-rootとする。 (Issue 1550)
• displayはアニメーション不可（離散アニメーションとも異なる）であることを明確化。 (Issue 2938)
• 軽微な編集修正。

2017年7月20日作業草案以降の変更点：

• blockificationのルールを厳密化し、inline-block / inline flow-rootのCSS2互換性確保。 (Issue 1246) run-in flow-rootも同様に更新。 (Issue 1715)

• displayの文法を調整し、list-itemキーワードを最後に記述。これはシリアライズ順にも影響。 (Issue 1621)

• ブロック整形コンテキストとインライン整形コンテキストの相互作用を、インライン整形コンテキストを確立するブロックコンテナの場合でより明確化。 (Issue 1553)

• 要素が複数ボックスを生成する場合に、プロパティ値が要素とボックス間でどのように反映されるかをより明確化。 (Issue 1643)

• 空のテキストオブジェクトはCSS描画で無視されることを明確化。 (Issue 1808)

• displayが文書の意味論に影響しないことを明確化（UAによくあるバグなので）。 (Issue 2355)

• displayの算出値の定義誤り修正（blockificationやinlinificationルールによって「as specified」でないため）。 (Issue 1716)

• 文書順の定義追加。

• 付録Bのdisplay: contents詳細にSVG要素追加(Issue 2118)、SVG属性の効果明確化(Issue 2502)、MathMLの挙動定義(Issue 2167)。

• 匿名ボックス構築規則の将来仕様著者向けガイダンス追加。 (Issue 1643)

• 「整形コンテキスト化」のセクションをCSS Containmentに戻した。

• 細かな文言修正・明確化。

2017年1月26日作業草案以降の変更点：

• inline-list-item値を削除（inline list-itemと同等のため）。

• テキストノードの概念を要素ツリーに追加、「text run」をボックスツリーに追加し、display: contentsの文脈での挙動定義。 (Issue 19, Issue 32)

• ルート要素が「インフロー」である旨の定義追加。 (Issue 3)

• ::first-line/::first-letterとrun-inの相互作用を定義。 (Issue 5, Issue 42)

• block/inline/run-inはフローレイアウトでのみ挙動を決定し、他のコンテキストでは無視されることを明確化。

• run-inはインラインボックスの一種であり、単に「似ている」だけではないことを明確化。

• run-inのボックスツリー操作に再帰性がなかった問題を修正。 (Issue 45)

• 「unusual elements」へのdisplay: contentsの働き方に関する付録追加。 (Issue 8, Issue 18)

• blockification・inlinificationのルール修正（特にレイアウト内部型の扱い）。 (Issue 35, Issue 57)

• 各種ボックスツリー修正の相互作用を明確化。 (Issue 38, Issue 48)

• 「整形コンテキスト化」の定義追加。

• その他細かな修正・明確化。

コメント処理状況も利用可能。

2015年10月15日作業草案以降の変更点：

• box-suppress/display-or-notプロパティをDisplay次レベルへ繰り越し、ユースケース議論の時間確保。
• display: contentsが置換要素やフォームコントロールなどの特殊要素に与える影響を明確化。
• 要素自身のボックスがdisplay: contentsで生成されない場合も、::beforeや::after疑似要素は引き続き存在することを明確化。
• display: contentsによるイベントバブリングには影響しないことを明確化。
• run-inとアウトオブフロー要素や::first-letterの相互作用明確化。
• table-captionやtable-cellのflow-root内側display型への切替（常に整形コンテキストの根になるため）。
• 残りの課題を終了し、リスクありリスト追加。

2015年7月21日作業草案以降の変更点：

• インフロー・アウトオブフローの定義を用語集に追加。

2014年9月11日作業草案以降の変更点：

• display-inside、display-outside、display-extrasロングハンドを削除し、displayをマルチ値化。 （これは組み合わせ可能な内容に制約を設けるため。今後の仕様レベルで不要となれば、制約を緩和する可能性あり。）
• flowとflow-rootの内側display型を新設し、フローレイアウトdisplay型やBFC根の明示的切り替えを表現。 （::after { clear: both; }やoverflow: hiddenのようなハックが不要になるはず。）

プライバシーに関する考慮事項

この仕様は新たなプライバシーの考慮事項を導入しません。

セキュリティに関する考慮事項

この仕様は新たなセキュリティの考慮事項を導入しません。

自己レビュー質問票

自己レビュー質問票：セキュリティとプライバシー：検討すべき質問より

1. この仕様は個人識別情報を扱いますか？

   いいえ。

2. この仕様は高価値データを扱いますか？

   いいえ。

3. この仕様はOriginの新しい状態を導入し、ブラウジングセッション間で持続しますか？

   いいえ。

4. この仕様は永続的なクロスオリジン状態をウェブに公開しますか？

   いいえ。

5. この仕様は他にアクセスできないデータをOriginに公開しますか？

   いいえ。

6. この仕様は新しいスクリプト実行／ロード機構を導入しますか？

   いいえ。

7. この仕様はOriginにユーザーの位置情報へのアクセスを許可しますか？

   いいえ。

8. この仕様はOriginにユーザーのデバイスのセンサーへのアクセスを許可しますか？

   いいえ。

9. この仕様はOriginにユーザーのローカルコンピューティング環境の側面へのアクセスを許可しますか？

   いいえ。

10. この仕様はOriginに他のデバイスへのアクセスを許可しますか？

    いいえ。

11. この仕様はOriginにUAのネイティブUIの制御を許可しますか？

    いいえ。

12. この仕様は一時的な識別子をウェブに公開しますか？

    いいえ。

13. この仕様はファーストパーティとサードパーティの文脈で挙動を区別しますか？

    いいえ。

14. この仕様はUAの「シークレットモード」でどのように動作すべきですか？

    変わりません。

15. この仕様はユーザーのローカルデバイスにデータを保存しますか？

    いいえ。

16. この仕様は「セキュリティの考慮事項」「プライバシーの考慮事項」セクションを持っていますか？

    はい。

17. この仕様はデフォルトのセキュリティ特性をダウングレードすることを許可しますか？

    いいえ。