CSS 表示モジュール レベル 3

1. 序論

このセクションは規範的である。

CSS は、 ツリー をなす 要素 （他の 要素 と テキストノードを混在して含められる） および テキストノード （テキストを含められる）として構成されたソース文書を受け取り、 それを画面、紙片、または音声ストリームのような キャンバス上に描画する。 そのようなソース文書はいずれも CSS により描画できるが、 最も一般的に用いられる型は DOM である。[DOM] （これらのより複雑なツリー型の一部には、 DOM におけるコメントノードのように、追加の種類のノードがあり得る。 CSS の目的においては、 これらの追加の種類のノードはすべて、 存在しないかのように無視される。）

これを行うため、CSS は中間構造である ボックスツリーを生成する。 これは描画される文書の整形構造を表す。 ボックスツリー内の各 ボックス は、 キャンバス上の空間および／または時間において対応する 要素（または 疑似要素）を表し、 一方、ボックスツリー内の各 テキスト列 も同様に、 対応する テキストノードの内容を表す。

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

次に、各 要素について、 CSS はその要素の display プロパティで指定されるとおりに、 0 個以上の ボックスを生成する。 通常、要素は単一の ボックス、 すなわち 主ボックスを生成し、 それは ボックスツリー内で自身を表し、その内容を含む。 しかし、一部の display 値 （例: display: list-item）は 複数のボックス （例: 主ブロックボックスと子の マーカーボックス）を生成する。 また、一部の値 （none や contents など）は、 要素および／またはその子孫に ボックスをまったく生成させない。 ボックスは、その display 型によって言及されることが多い—​例えば display: block を持つ要素によって生成される ボックスは “ブロックボックス” または単に “ブロック” と呼ばれる。

ボックスには、別途示されない限り、 それを生成する 要素と同じスタイルが割り当てられる。 一般に、継承プロパティは 主ボックスに割り当てられ、 その後ボックスツリーを通じて、 同じ要素によって生成された他のすべてのボックスへ継承される。 非継承プロパティは既定で 主ボックスに適用されるが、 要素が複数のボックスを生成する場合、 別のボックスに適用されるよう定義されることがある: 例えば、テーブル要素に適用される border プロパティは、 その 主 テーブル ラッパーボックスではなく、 テーブルグリッドボックスに適用される。 値の算出処理がそれらのボックスのスタイルを変更し、 要素のスタイルが （getComputedStyle() などを通じて） 要求された場合、 その要素は、 各プロパティについて、 そのプロパティが適用されたボックスからの値を反映する。

同様に、兄弟である連続した テキストノードの各列は、 そのテキスト内容を含む テキスト列を生成し、 それを生成する テキストノードと同じスタイルが割り当てられる。 ただし、その列にテキストが含まれない場合は、 テキスト列を生成しない。

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

匿名ボックスは、いかなる要素にも関連付けられていないボックスである。 匿名ボックスは、 特定の状況において、 ボックスツリーが、 要素ツリーから生成されるボックスによって提供されない 特定の入れ子構造を必要とする場合に、それを補正するため生成される。 例えば、テーブルセルボックスは、 特定の種類の親ボックス（テーブル行ボックス）を必要とし、 その親が テーブル行ボックスでない場合には、 自身の周囲に 匿名の テーブル行ボックスを生成する。 （[CSS2] § 17.2.1 を参照。） スタイルが厳密に要素ツリーを通じて継承される、要素から生成されるボックスとは異なり、 匿名ボックス（ボックスツリー内にのみ存在する）は、 継承を、それらの ボックスツリー上の親子関係を通じて行う。

レイアウトの過程で、 ボックスおよび テキスト列は、複数の 断片に分割されることがある。 これは、例えば インライン ボックスおよび／または テキスト列が 行をまたいで分割される場合、 または ブロックボックスが ページや段をまたいで分割される場合に起こり、 この処理は 断片化と呼ばれる。 また、テキストの bidi 並べ替え （CSS Writing Modes の 双方向並べ替え アルゴリズムの適用を参照） や、より高次の 表示型の ボックス分割、 例: block-in-inline 分割 （CSS2§9.2 を参照） または column-spanner-in-block 分割 （CSS Multi-column Layout を参照） によっても起こり得る。 したがって、ボックスは 1 つ以上の ボックス断片から構成され、 テキスト列は 1 つ以上の テキスト断片から構成される。 断片化の詳細については [CSS-BREAK-3] を参照。

注: CSS 仕様の多くは、この用語体系が整えられる前に 書かれたものであるか、 物事を誤って参照しているため、 古い仕様がこれらの用語を使っている場合は注意して読むこと。 文脈から、それらが実際にはどの用語を意味しているかを推測できるはずである。 誤りを見つけた場合は、修正できるように仕様内の 誤りを報告されたい。

注: “聴覚” ボックスツリー およびそれと display プロパティとの相互作用に関する追加情報は、 CSS Speech Module にある。 [CSS-SPEECH-1]

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

このモジュールは、[CSS2] セクション 9.2.4 で定義されている display プロパティの定義を置き換え、拡張する。

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

1.2. 値の定義

この仕様は、[CSS2] 由来の CSS プロパティ定義の慣例に従い、 [CSS-VALUES-3] 由来の 値定義構文を用いる。 この仕様で定義されない値型は、CSS Values & Units [CSS-VALUES-3] で定義される。 他の CSS モジュールとの組み合わせにより、これらの値型の定義は拡張されることがある。

各定義に列挙されるプロパティ固有の値に加えて、 この仕様で定義されるすべてのプロパティは、 そのプロパティ値として CSS 全域キーワードも受け入れる。 読みやすさのため、それらは明示的には繰り返していない。

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

ユーザーエージェントは、非視覚的なものを含むすべての媒体でこのプロパティをサポートすることが期待される。 display プロパティは、要素の 表示型を定義する。 これは、要素がどのようにボックスを生成するかについての 2 つの基本的性質から成る:

• 内側表示型。 これは（置換されない要素である場合に）生成する 整形文脈の種類を定義し、 その子孫ボックスがどのようにレイアウトされるかを決定する。 （置換要素の内側表示は CSS の範囲外である。）

• 外側表示型。 これは 主ボックス自体が フローレイアウトにどのように参加するかを決定する。

テキスト列は 表示型を持たない。

一部の 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> キーワードは、要素の 外側表示型を指定する。 これは本質的に、フロー レイアウトにおける、その 主 ボックスの役割である。 それらは次のように定義される:

block

要素は、フロー レイアウト内に置かれたとき ブロックレベル であるボックスを生成する。[CSS2]

inline

要素は、フロー レイアウト内に置かれたとき インラインレベル であるボックスを生成する。[CSS2]

run-in

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

注: 外側表示型は、置換要素に影響する。

<display-outside> 値が指定されているが、<display-inside> が省略されている場合、 要素の 内側 表示型は flow になる。

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

<display-inside> キーワードは、要素の 内側表示型を指定する。 これは、その内容をレイアウトする整形文脈の型を定義する （それが 置換されない要素であると仮定する）。 それらは次のように定義される:

flow

要素は、その内容を フローレイアウト （ブロックおよびインラインレイアウト）を用いてレイアウトする。

その 外側 表示型が inline または run-in であり、 かつ、それが ブロック または インライン 整形文脈に参加している場合、 それは インライン ボックスを生成する。

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

他のプロパティの値（例えば position、float、または overflow など） および、それ自身がブロックまたはインラインの 整形文脈に参加しているかどうかに応じて、 それは、その内容のために新たな ブロック整形文脈を確立するか、 またはその内容を親の 整形 文脈に統合する。 CSS2.1 第 9 章を参照。[CSS2] 新たな ブロック整形文脈を確立する ブロックコンテナは、 使用 内側表示型として flow-root を持つとみなされる。

flow-root

要素は ブロックコンテナボックスを生成し、 その内容を フローレイアウトを用いてレイアウトする。 それは常に、その内容のために新たな ブロック整形文脈を確立する。[CSS2]

table

要素は、ブロック整形文脈を確立する、主たる テーブル ラッパーボックスを生成し、 それは、追加で生成される テーブルグリッド ボックスを含み、 そのボックスは テーブル整形文脈を確立する。[CSS2]

flex

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

grid

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

（subgrid を用いるグリッドは、新たな グリッド整形文脈を生成しないことがある。 詳細は [CSS-GRID-2] を参照。）

ruby

要素は ルビコンテナボックスを生成し、 ルビ整形文脈を確立する。 それに加えて、その基底レベルの内容を 親の 整形文脈へ統合する （それがインラインである場合）、 または適切な 外側表示型のラッパーボックスを生成する （それがインラインでない場合）。[CSS-RUBY-1]

<display-inside> 値が指定されているが、<display-outside> が省略されている場合、 要素の 外側 表示型は既定で block になる—​ただし ruby は例外で、既定で inline になる。

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

list-item キーワードは、 その list-style プロパティで指定される内容を持つ ::marker 疑似要素 [CSS-PSEUDO-4] （CSS 2.1§12.5 Lists）[CSS2] を、その自身の内容のための指定された型の主ボックスとともに、要素に生成させる。

内側表示 型値が指定されていない場合、 主ボックスの 内側表示型は既定で flow になる。 外側表示 型値が指定されていない場合、 主ボックスの 外側表示型は既定で block になる。

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

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

table や ruby のような一部のレイアウトモデルは、 子および子孫が担うことのできる複数の異なる役割を備えた、 複雑な内部構造を持つ。 このセクションは、そのような “レイアウト内部” display 値を定義する。 これらは、その特定のレイアウトモード内でのみ意味を持つ。

別途指定されない限り、 これらの display 値を用いる要素の 内側表示 型と 外側表示型は、 どちらも与えられたキーワードに設定される。

置換要素の display プロパティが レイアウト内部 値のいずれかに算出される場合、 それは使用値として inline を持つものとして扱われる。 空白の畳み込みおよび匿名ボックス生成は、 それらの置換要素の周囲でその inline 値に基づいて行われなければならない。 それらに レイアウト内部表示値が適用されたことが ないかのように扱う。

作者は レイアウト内部表示値を 置換要素に割り当てるべきではない。

<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 内側表示型を持つ。

table-caption

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

table-caption ボックスは、flow-root 内側表示型を持つ。

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

要素は 内部ルビ要素である。 それは、ルビ整形文脈に参加する適切な 内部ルビボックスを生成する。[CSS-RUBY-1]

ruby-base および ruby-text は、flow 内側表示型を持つ。

レイアウト固有の表示型を持つボックスは、 互換性のない親内に配置された場合、 それぞれの仕様で定義されるように、自身の周囲に匿名ラッパーボックスを生成する。

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

ブロックボックス
└匿名テーブルボックス
 └匿名 table-row-group ボックス
  └匿名 table-row ボックス
   └table-cell ボックス

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

table ボックス
└匿名 table-row-group ボックス
 └table-row ボックス
  └table-cell ボックス

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

display は、要素が生成するボックスの型を制御できる一方で、 要素がそもそもボックスを生成するかどうかも制御できる。

<display-box> キーワードは次のように定義される:

contents

要素自身はいかなるボックスも生成しないが、 その子および疑似要素は通常どおり ボックスおよび テキスト列を生成する。 ボックス生成およびレイアウトの目的において、 その要素は、要素ツリー内で、 その内容によって置き換えられたかのように扱われなければならない （ソース文書の子と疑似要素の両方を含む。 例えば ::before および ::after 疑似要素などで、 これらは通常どおり要素の子の前／後に生成される）。

注: 影響を受けるのはボックスツリーのみであるため、 セレクタ照合、イベント処理、 およびプロパティの 継承のような、 文書ツリーに基づく意味論はいずれも影響を受けない。 しかし執筆時点では、 これは主要ブラウザーで正しく実装されていないため、 Web 上でこの機能を用いる場合は注意して行わなければならない。 これはアクセシビリティツールが 要素の意味論にアクセスすることを妨げる可能性があるためである。

この値は、置換要素およびレンダリングが CSS によって完全には制御されない他の要素では display: none に算出される。 詳細は 付録 B: 特殊な要素に対する display: contents の効果を参照。

注: 置換要素およびフォームコントロールは 特別に扱われる。 要素自身が生成するボックスだけを取り除くことは、 多かれ少なかれ未定義の操作であるためである。 この挙動は、ユースケース （およびより精密なレンダリングモデル）が発展すれば洗練される可能性があるため、 作者は前方互換性のため、そのような要素では display: contents ではなく display: none を用いるべきである。

none

要素およびその子孫は、 ボックスも テキスト列も生成しない。

同様に、テキストノードが display: none として振る舞うよう定義されている場合、 それは テキスト列を生成しない。

これらの値のいずれかを持つ要素は、内側または 外側表示型を持たない。 なぜなら、それらはそもそもいかなるボックスも生成しないためである。

注: これらの値は、影響を受ける要素にボックスを生成させないため、 匿名ボックス生成規則は省略された要素を完全に無視し、 それらがボックスツリー内に存在しないかのように扱う。

しかし、マークアップに基づく関係はこれらの値の影響を受けない。 それらは純粋にレンダリング時の効果であるためである。 例えば、 それらはどのテーブルセルが列に見えるかに影響し得るものの、 特定の列要素に関連付けられるテーブルセルには影響しない。 同様に、それらはどの HTML summary 要素が特定のテーブルに関連付けられるか、 または legend が特定の fieldset の内容をラベル付けしているとみなされるかには影響できない。

2.6. 合成済みインラインレベル表示値

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. 自動ボックス型変換

一部のレイアウト効果は、ボックス型の ブロック化 または インライン化を必要とする。 これはボックスの 算出 外側表示型を block または inline（それぞれ）に設定する。 （これは、表示型のうち、 none や contents のように、 そもそもボックスを生成しないものには影響しない。） さらに:

• ブロックボックス（block flow）が インライン化される場合、 その 内側 表示型は flow-root に設定され、 ブロックコンテナのままでいられるようにする。

• インラインボックス（inline flow）が インライン化される場合、 それは自身のすべての 通常フロー内の子を再帰的に インライン化し、 ブロックレベルの子孫が、 それが参加しているインライン整形文脈を分断しないようにする。

• 旧来の理由により、 インラインブロックボックス （inline flow-root）が ブロック化される場合、 それは block ボックスになる （その flow-root としての性質を失う）。 一貫性のため、 run-in flow-root ボックスも ブロック化されて block ボックスになる。

• レイアウト内部ボックスが ブロック化される場合、 その 内側 表示型は flow に変換され、 それが ブロックコンテナになるようにする。 インライン化は レイアウト内部ボックスには影響しない。 （ただし、そのようなインライン文脈内に配置されると、 通常はそれらが適切な型の匿名インラインレベルボックスで ラップされることになる。）

注: ボックスが自身の文脈に適合しない場合に ボックス型を修正するために用いられる方法は 2 つある。 1 つは、ここで説明した ブロック化や インライン化のような、 display の 算出値の変換である。 もう 1 つは、ボックスツリー構築中（算出値が決定された後）に行われる、 中間的な匿名ボックスの作成である。 これは テーブル、 ルビ、 および フローレイアウトで起こるようなものである。

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

ルート要素の表示型は 常に ブロック化され、 その 主ボックスは常に 独立整形文脈を確立する。 このボックスの 包含 ブロックは 初期包含ブロックである。

さらに、ルート要素上の display の contents は、block に算出される。

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

ボックスは一般に、ソース文書内に現れるのと同じ順序で 表示され、レイアウトされる。 一部の 整形 文脈では、 order プロパティを用いてボックスの順序を並べ替え、 要素の論理順序と、 2D 視覚キャンバス上での空間的配置との不一致を 意図的に作り出すことができる。 （§ 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">
  <h3>コンピューター入門キット</h3>
  <p>これは、あまりお金がないなら、お金で買える最高のコンピューターである。
  <ul>
    <li>コンピューター
    <li>モニター
    <li>キーボード
    <li>マウス
  </ul>
  <img src="images/computer.jpg"
    alt="入手できるもの: 白いデスクトップコンピューターと、それに合う周辺機器。"
    width="250" height="188">
</article>

コンピューター入門キット

これは、お金で買える最高のコンピューターである。 あまりお金がないなら。

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

Flex および グリッドコンテナは、 その内容を order 修正済み文書順でレイアウトする。 最も小さい番号の順序グループから始めて上がっていく。 同じ順序グループを持つアイテムは、ソース文書に現れる順序でレイアウトされる。 これは 描画順序 [CSS2]にも影響する。 あたかも flex/grid アイテムが ソース文書内で並べ替えられたかのように扱われる。 flex/グリッドコンテナの絶対配置された子は、 flex/grid アイテムに対する描画順序を 決定する目的では、order: 0 を持つものとして扱われる。

将来の仕様によって別途指定されない限り、 このプロパティは フレックスアイテムまたは グリッド アイテムでないボックスには影響しない。

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

order プロパティは、非視覚媒体 （音声など）における順序には 影響しない。 同様に、order は、 逐次ナビゲーションモードの既定の巡回順序 （リンクを順にたどる場合など。例えば tabindex [HTML]を参照）にも影響しない。

作者は、内容の論理的な並べ替えではなく、空間的な並べ替えのためにのみ order を用いなければならない。 order を用いて論理的な並べ替えを行う スタイルシートは適合しない。

注: これは、通常は内容を線形に提示する非視覚媒体および 非 CSS UA が、論理的なソース順序に依存できるようにしつつ、 order がレイアウト順序の調整に用いられるようにするためである。 （視覚知覚は二次元かつ非線形であるため、 望ましいレイアウト順序が常に論理的であるとは限らない。）

すべての提示モードにおいて作者の意図した順序を保つために、 WYSIWYG エディターや Web ベースのオーサリング支援を含むオーサリングツールは、 下層の文書ソースを並べ替えなければならず、 作者が、空間的順序を （音声およびナビゲーション順序を決定する）下層の文書順序と 同期させないべきであると明示的に示した場合を除き、 並べ替えを行うために order を用いてはならない。

注: ブラウザー、アクセシブル技術、拡張機能を含むユーザーエージェントは、 空間ナビゲーション機能を提供することがある。 このセクションは、そのような空間ナビゲーションモードにおける要素順序を決定する際に order プロパティを尊重することを妨げない。 実際、そのような機能が動作するためには考慮する必要があるだろう。 しかし、order は、 そのような空間ナビゲーション機能のために考慮する必要のある 唯一の（あるいは主要な）CSS プロパティではない。 適切に実装された空間ナビゲーション機能は、 空間的関係を変更する CSS のすべてのレイアウト機能を考慮する必要がある。

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

visibility プロパティは、ボックスが描画されるかどうかを指定する。 不可視ボックスはなお レイアウトに影響する。 （ボックス生成そのものを抑止するには、display プロパティを none に設定する。）。 値は次の意味を持つ:

visible

生成されたボックスは通常どおり可視である。

hidden

要素によって生成されたすべてのボックスは 不可視になる。 ただし、要素の子孫は visibility: visible を持つ場合、 可視になり得る。

collapse

ボックスが 折りたたまれることを示す。 これは整形文脈固有の方法で、 通常より少ない空間を占める原因となり得る。 テーブルにおける動的な行および列の効果 [CSS2] および flex レイアウトにおける 折りたたまれたフレックスアイテム [CSS-FLEXBOX-1]を参照。 ただし、それ以外のすべての場合 （すなわち、別途指定されない限り）、 これは hidden と同様に、 単にボックスを 不可視にする。

注: 現在、多くのユーザーエージェントおよび／またはアクセシビリティ ツールは、 不可視要素と意味的関係を持つ可視要素に関する アクセシビリティ上の含意を正しく実装していない。 そのため、例えば、 特別なロールを持つ親要素（テーブル行など）を 不可視にしつつ、 特別なロールを持つ子要素（テーブルセルなど）を可視のままにすることは、 それらのツールのユーザーにとって問題となり得る。 作者は、ツールの状況が改善するまで、 このような状況を作り出すことを避けるべきである。

不可視ボックスは描画されず （完全に透明であるかのように）、 対話できず （pointer-events: none を持つかのように振る舞う）、 ナビゲーションから除去され （display: none と同様）、 音声にも描画されない （ただし speak が always である場合を除く [CSS-SPEECH-1]）。 しかし、display: contents と同様に、 コンテナとしての意味的役割は影響を受けない。 これは、任意の 可視の子孫が 適切に解釈されることを保証するためである。

注: 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. Run-In レイアウト

run-in ボックスは、 その後に来るブロックへ併合し、 そのブロックのインラインレベル内容の先頭に自身を挿入するボックスである。 これは、コンパクトな見出し、定義、その他類似のものを整形するのに有用である。 その場合、適切な 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.

run-in ボックスは、任意の他の インラインレベルボックスと まったく同じように振る舞うが、次の場合を除く:

• run-in ボックスが flow 内側表示 型を持つ場合、その内容を インライン化する。
• run-in 列の直後に、 新たな ブロック整形文脈を確立しないブロックボックスが続く場合、 それはそのブロックボックスの直接の子として挿入される: その ::marker 疑似要素のボックス（もしあれば）の後で、 かつそのブロックの内容によって生成される他のすべてのボックス （::before 疑似要素によって生成されるボックスがある場合はそれを含む） より前に挿入される。 この親の付け替えは可能であれば再帰する （そのため run-in は実質的に、 その整形文脈における最も深い後続の “段落” の一部となり、 その過程で新たに隣接した run-in を集める）。

  親が付け替えられた内容は、もともとそこを親としていたかのように整形される。 レイアウトのみが影響を受け、継承は影響を受けないことに注意。 非匿名ボックスのプロパティ継承は要素ツリーのみに基づくためである。

• それ以外の場合 （run-in 列の後にそのようなブロックが続かない場合）、 run-in 列と直後に続くすべてのインラインレベル内容 （次の run-in 列がある場合は、その直前まででそれを含まない） の周囲に匿名ブロックボックスが生成される。

run-in 列は、 連続する兄弟 run-in ボックスと、 その間に介在する 空白および／または フロー外ボックスの最大列である。

注: この記述は、フロー外ボックスが 2 つの run-in ボックスの間にある場合に親を付け替えられることを意味する。 別の選択肢としては、介在するフロー外ボックスを残しておくこと、 またはフロー外ボックスが前のボックスの run-in 化を妨げるようにすることもあり得る。 実装者および作者は、好ましい挙動がある場合には CSSWG に連絡することが推奨される。 これはいくぶん無作為に選ばれたものだからである。

この修正は、CSS2§9.2 で説明される 匿名ブロックおよびインラインボックス修正の前に起こり、 影響を受ける要素の 最初の 整形行の決定に影響する。 これは run-in 列が もともとボックスツリー内の最終位置にあったかのように扱われる。

注: 最も早い run-in は、その包含ブロックの 最初の整形行上の最初のテキストを表すため、 そのブロック要素に適用された ::first-letter 疑似要素は、 自身の内容の最初の文字ではなく、 run-in の最初の文字を選択する。

注: この run-in モデルは、 [CSS2] の以前の改訂で 提案されていたものとは少し異なる。

付録 A: 用語集

便宜のため、次の用語をここで定義する:

ルート要素

文書ツリーの根にある 要素。 DOM の下で生成される 文書ツリーでは、 これは 文書要素であり、 HTML では html 要素である。 [DOM] [HTML]

主ボックス

要素が 1 つ以上の ボックスを生成する場合、 そのうちの 1 つが 主 ボックスである。 これはその子孫ボックスおよび生成内容を含み、 さらに任意の位置決め方式に関与するボックスでもある。

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

インラインレベル

インラインレイアウトに参加する内容。 具体的には、インラインレベルボックスおよび テキスト列。

ブロックレベル

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

インラインボックス

内側 表示型が flow である、置換されない インラインレベル ボックス。 インラインボックスの内容は、インラインボックス自身と同じインライン整形文脈に参加する。

インライン

曖昧でない場合に、インライン ボックスまたは インラインレベルボックスの短縮表現として用いられる。 または インラインレベルを意味する形容詞として用いられる。 後者の用法は非推奨である。

不可分インライン

置換される（画像など）、 または新たな整形文脈を確立する（inline-block や inline-table など） インラインレベルボックスであり、 行をまたいで分割できないもの （インラインボックスや ルビコンテナは分割できる）。

内側表示型が 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]を参照。

ユーザーエージェントは、 置換要素が持つ 自然寸法が 第三者へ機微情報を漏らし得ると考えられる場合、 その置換要素を自然寸法を持たないものと見なしてもよい。 例えば、HTML 文書の自然サイズがユーザーの銀行残高に応じて変化する場合、 UA はそのリソースに 自然寸法がないかのように振る舞いたいかもしれない。

置換要素の内容は CSS 整形モデルにおいて考慮されない。 しかし、その 自然寸法は各種レイアウト計算で用いられる。 置換要素は常に 独立整形文脈を確立する。

非置換要素とは、 置換されない要素、 すなわちそのレンダリングが CSS モデルによって決定される要素である。

包含ブロック

それに関連付けられた ボックスの サイズ決定および位置決めの基礎となる矩形。 特に、包含 ブロックはボックスではない （矩形である）が、 しばしば ボックスの寸法から導かれる。 各 ボックスには、それ自身の 包含ブロックを基準とした位置が与えられる。 しかし、それはこの 包含ブロックに閉じ込められるわけではなく、 オーバーフローし得る。 “a box’s containing block” という句は、 “そのボックスが存在する 包含ブロック” を意味し、 それが生成するものを意味しない。

一般に、ボックスの 辺は、 子孫ボックスの 包含ブロックとして機能する。 ボックスがその子孫のための 包含ブロックを “確立する” という。 包含ブロックのプロパティが参照される場合、 それらはその 包含ブロックを生成した ボックス上の値を参照する。 （初期包含ブロックについては、 別途指定されない限り、値はルート要素から取得される。）

詳細は [CSS2] セクション 9.1.2 および セクション 10.1 および CSS Positioned Layout 3 § 2.1 位置指定ボックスの包含ブロックを参照。

包含ブロック 連鎖

包含ブロック関係を通じて、 祖先子孫連鎖を形成する、 連続する 包含ブロックの列。 例えば、インラインボックスの 包含ブロックは、最も近い ブロックコンテナ祖先の内容ボックスである。 そのブロックコンテナが 通常フロー内の ブロックであれば、 その包含ブロックは、その親 ブロック コンテナによって形成される。 その祖親の ブロックコンテナが 絶対配置されている場合、 その包含ブロックは、最も近い位置指定祖先（必ずしも親ではない）のパディング辺であり、 以下、初期包含ブロックまで続く。

初期 包含ブロック

ルート 要素の 包含 ブロック。 初期包含ブロックは ブロック 整形文脈を確立し、 文書の 主書字モードを取る （CSS Writing Modes 4 § 8.1 初期包含ブロックへの伝播を参照）。 連続媒体では、 それは 小ビューポートサイズの寸法を持ち、 キャンバス原点に固定される。 ページ媒体では、その位置と寸法について [CSS-PAGE-3]を参照。

整形 文脈

整形 文脈とは、 関連するボックスの集合がレイアウトされる環境である。 異なる 整形文脈は、 異なる規則に従ってそのボックスをレイアウトする。 例えば、フレックス整形文脈は、 フレックスレイアウト 規則に従ってボックスをレイアウトする [CSS-FLEXBOX-1]。 一方、ブロック整形文脈は、 ブロックおよびインラインレイアウト規則に従ってボックスをレイアウトする [CSS2]。 さらに、いくつかの型の 整形文脈は 交錯し、共存する: 例えば、インライン整形文脈は、 それを確立する要素の ブロック整形文脈の中に存在し、 それと相互作用する。 また ルビコンテナは、その ルビベースコンテナが参加する インライン整形文脈の上に ルビ整形文脈を重ねる。

ボックスは新たな 独立整形文脈を確立するか、 その包含ブロックの 整形文脈を継続する。 場合によっては、 さらに新たな（独立でない）共存する整形文脈を確立することもある。 しかし、別途指定されない限り、 新たな 整形文脈を確立することは、 独立整形文脈を作成する。 ボックスによって確立される整形文脈の型は、 その 内側表示型によって決定される。 例えば、グリッドコンテナは新たな グリッド整形文脈を確立し、 ルビコンテナは新たな ルビ整形文脈を確立し、 ブロック コンテナは新たな ブロック整形文脈 および／または新たな インライン整形文脈を確立できる。 display プロパティを参照。

独立 整形文脈

ボックスが独立整形文脈を確立する場合 （その 整形文脈が親と同じ型であるか否かにかかわらず）、 それは本質的に、新たな独立したレイアウト環境を作成する: ボックス自身のサイズ決定を通じる場合を除き、 その子孫のレイアウトは（一般に）、 ボックスの外側の 整形文脈の 規則や内容によって影響を受けず、その逆も同様である。

例えば、ブロック整形文脈では、 浮動ボックスは周囲のボックスのレイアウトに影響する。 しかし、その効果は自身の 整形文脈から外へ出ない: それらの 整形文脈を確立するボックスは、 それらを完全に含むように成長し、 そのボックスの外側からの浮動は、 ボックス内の内容へ突き出して影響することを許されない。

別の例として、マージンは 整形文脈の境界を越えて相殺されない。

排除は、独立 整形文脈の境界を越えて内容に影響できる。 （執筆時点では、それが可能な唯一のレイアウト機能である。） [CSS3-EXCLUSIONS]

特定のプロパティは、 通常ならそうしない場合でも、ボックスに 独立整形文脈を確立することを強制できる。 例えば、 ボックスを フロー外にすると、 それは ブロック化されると同時に 独立整形 文脈を確立する。 別の例として、 contain プロパティの特定の値は、 ボックスに 独立 整形文脈を確立させることができる。 ブロックを スクロールコンテナに変えると、 それは 独立 整形文脈を確立する。 しかし subgrid を スクロール コンテナに変えてもそうはならない—​それは subgrid として振る舞い続け、 その内容は親の グリッド コンテナのレイアウトに参加する。

ブロックボックスが 独立整形 文脈を確立する場合、 その内容のために新たな ブロック整形文脈を確立する。 ほとんどの他の場合、 ボックスに 独立 整形文脈を確立することを強制しても何もしない—​そのボックスがすでに 独立整形文脈を確立している （例: フレックスコンテナ）か、 その型のボックスに完全に独立した新たな整形文脈を確立することが不可能 （例: 置換されない インライン ボックス）であるためである。

ブロック整形 文脈

インライン 整形文脈

ブロックおよび インライン整形 文脈は、 CSS 2.1 セクション 9.4で定義される。 インライン整形文脈は、 ブロック整形文脈内に存在する （それを含むものの一部である）。 例えば、インライン整形 文脈に属する行ボックスは、 ブロック整形 文脈に属する浮動と相互作用する。

ブロックレイアウト

ブロックレベル ボックスのレイアウトであり、 ブロック整形文脈内で行われる。

ブロック 整形文脈ルート

新たな ブロック整形文脈を確立する ブロックコンテナ。

BFC

ブロック整形文脈または ブロック整形文脈ルートの略語。 内部の浮動を含み、外部の浮動を排除し、マージン相殺を抑止するボックスを指す さまざまな非公式な定義があり、 したがって特に次のいずれかを指し得る:

• その内容のために新たな ブロック整形文脈を確立する ブロック コンテナ

• その内容のために ブロック整形文脈を確立する ブロックボックス （すなわち ブロックレベルの ブロックコンテナ） （そうでないブロックボックスと区別して）

• （かなり緩く）新たな 整形文脈 （インライン整形文脈以外）を確立する任意のブロックレベルボックス

フロー外

通常フロー内

ボックスが、期待される位置および周囲の内容との相互作用から取り出され、 その親整形文脈内の通常の内容フローの外側で、 異なるパラダイムを用いてレイアウトされる場合、 そのボックスは フロー外である。 これは、ボックスが（float によって） 浮動される場合、または（position によって） 絶対配置される場合に起こる。 ボックスが フロー外でない場合、 そのボックスは 通常フロー内である。

注: 一部の 整形文脈は 浮動を抑止するため、 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 によれば、 display: contents を持つ legend は 描画される legendではないため、 魔法のような表示挙動を持たない。 （したがって、それは display: contents に 通常どおり反応する。）

button

details

fieldset

これらの要素には特別な挙動はない。 display: contents は単にそれらの 主ボックスを除去し、 それらの内容は通常どおり描画される。

その他任意の HTML 要素

display: contents について通常どおり振る舞う。

SVG 要素

CSS ボックスレイアウトを持つ svg 要素 （これには、親が HTML 要素であるすべての svg と、文書のルート要素が含まれる）

display: contents は display: none に算出される。

それ以外のすべての SVG コンテナ要素で、かつ 描画可能要素でもあるもの

SVG テキスト内容子要素

use

display: contents は、その要素を整形ツリーから取り除き、 その内容を引き上げて、その場所に表示する。 これらの内容には、 use の shadow-DOM 内容が含まれる。

その他任意の SVG 要素

display: contents は display: none に算出される。

要素が整形ツリーから取り除かれる場合、 その要素上の、レイアウトおよび視覚整形を制御する SVG 属性は、 内容を描画するときに無視される。 しかし、CSS プロパティへ対応付けられる SVG プレゼンテーション属性は、 値処理および継承に影響し続ける [CSS-CASCADE-3]; したがって、そのような属性は、 それらの子孫上のそのようなプロパティの値に影響することによって、 要素の子孫のレイアウトおよび視覚整形に影響し得る。

MathML 要素

すべての MathML 要素について、 display: contents は display: none に算出される。

付録 C: 仕様作者のためのボックス構築ガイドライン

このセクションは、仕様作者向けの非規範的なガイダンスである。

• ボックスを同時に ブロック化し、かつ インライン化することはできない。 そのようなことが起こり得る場合は、 どちらが優先されるかを定義すること。

• 主でない非匿名ボックスは ブロック化できない: ブロック化は要素の算出値に影響し、 したがってその 主ボックスの型を決定する。

• 自身の内容を ブロック化する ボックスは、 インラインレベル内容を直接含むことができない。 そのような要素内で生成されるボックスまたはテキスト列は、 ブロック化されるか、 匿名 ブロックコンテナで ラップされなければならない。

• 自身の内容を インライン化する ボックスは、 ブロックレベルボックスを直接含むことができない。 そのような要素内で生成されるすべてのボックスは、 インラインレベルで なければならない。

• 本質的に 独立 整形文脈を確立できないボックス （置換されないインラインなど）には、 独立整形 文脈を確立することを求めてはならない。 まずそれらをブロック化するか、 または 独立整形文脈を確立できるものへ ボックス型を変更すること。

謝辞

長年にわたり、ボックス生成の多様な詳細を分離しようと試みてきた多くの人々に感謝したい。 とりわけ Bert Bos には、 彼の最後の試みである display-model と display-role はどこにも到達しなかったものの、 現在の仕様への下地を整えてくれたことに感謝する。 Anton Prowse には、 CSS2.1 第 9 章への容赦ない追及によって混沌から一定の秩序を引き出してくれたことに感謝する。 そして Oriol Brufau には、 この仕様における何十もの細かな区別や誤りを解きほぐしてくれたことに感謝する。 David Baron、Mats Palmgren、Ilya Streltsyn、 および Boris Zbarsky にも、フィードバックについて謝意を表する。

変更点

2023 年勧告候補スナップショット以降の変更点

2023 年 3 月 30 日の勧告候補 スナップショット以降の変更には、次が含まれる:

• 初期包含ブロックの 連続媒体における CSS2.1 の定義を本文中に取り込み、 [CSS-WRITING-MODES-4] で定義される 書字 モードの伝播を相互参照し、 それが 小ビューポートサイズを指すことを明確化した。 （Issue 6453）

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-…

  Behaves as Computes to inline ….

  注: これらのキーワードとその等価値は同じ値に算出されるが、 それらの 指定値は区別されたままである。

  注: getComputedStyle() の直列化規則は、 最短で、最も後方互換性のある 直列化原則により、 等価な 2 キーワードの組ではなく、 常にこれらの合成済みキーワードを出力する。

• ブロック化および インライン化が 算出値の変更であることを明確化した。 （Issue 6251）

  一部のレイアウト効果は、ボックス型の ブロック化 または インライン化を 必要とする。 これはボックスの 算出 外側 表示型を、 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” とより容易に区別できるようにした。
• ルート → 初期包含ブロックの伝播に “unless otherwise specified” を追加した。 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 日の作業草案以降の変更には、 次が含まれる:

• CSS2 との互換性を確保するため、 inline-block / inline flow-root の ブロック化規則を厳密化した。 （Issue 1246） run-in flow-root の処理も一致するよう更新した。 （Issue 1715）

• display の文法を調整し、 list-item キーワードを 最後に列挙するようにした。これは期待される直列化順序に影響する。 （Issue 1621）

• インライン整形文脈を確立するブロックコンテナにおける、 ブロック整形 文脈と インライン整形文脈の相互作用について、 より良い定義を追加した。 （Issue 1553）

• プロパティ値が要素とそのボックスとの間で反映される方法 （要素が複数のボックスを生成する場合）をより明確に定義した。 （Issue 1643）

• 空のテキストオブジェクトは CSS レンダリングにおいて無視されることを明確化した。 （Issue 1808）

• これは UA における一般的なバグであるため、 display が文書の意味論に影響しないことを明確化した。 （Issue 2355）

• display の 算出 値の定義における誤りを修正した （さまざまなプロパティによって引き起こされる ブロック化および インライン化規則により、 これは明らかに “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 値を削除した。

• display: contents の文脈における 挙動を定義するため、 “テキスト ノード” の概念を 要素ツリーに追加し、 “テキスト ラン” を ボックスツリーに 追加した。 （Issue 19, Issue 32）

• ルート要素は “in flow” であることを定義した。 （Issue 3）

• ::first-line/::first-letter と run-in の相互作用を定義した。 （Issue 5, Issue 42）

• block/inline/run-in は フローレイアウトにおける挙動のみを 指示するものであり、他の文脈では無視されることを明確化した。

• Run-in は、インラインボックス “のようなもの” ではなく、インラインボックスの一種である。

• run-in のボックスツリー操作に再帰が欠けていた問題を修正した。 （Issue 45）

• “特殊な要素” に対して display: contents がどのように機能するかに関する付録を追加した。 （Issue 8, Issue 18）

• 特にレイアウト内部型の処理について、 ブロック化および インライン化規則を修正した。 （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 を使用するように変更した。 それらは常に整形文脈ルートを形成するためである。
• 残りの課題を終了し、at-risk リストを追加した。

2015 年 7 月 21 日の作業草案以降の変更には、 次が含まれる:

• 用語集に in-flow および out-of-flow の定義を追加した。

2014 年 9 月 11 日の作業草案以降の変更には、 次が含まれる:

• display-inside、display-outside、および display-extras ロングハンドを削除し、 単に display を複数値にすることを採用した。 （これは、何を組み合わせられるかに制約を課すために行われた。 この仕様の将来のレベルでは、 それらの制約の一部または全部が不要または望ましくなくなった場合、 緩和される可能性がある。）
• flow および flow-root の 内側表示 型を作成した。 これにより、フローレイアウトの 表示型をよりよく表現し、 要素を BFC ルートにするための明示的なスイッチを作成する。 （これにより、この目的を達成するための ::after { clear: both; } や overflow: hidden のようなハックは不要になるはずである。）

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

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

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

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

自己レビュー質問票

自己レビュー質問票: セキュリティとプライバシー: 考慮すべき質問に従う

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

   いいえ。

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

   いいえ。

3. この仕様は、閲覧セッションをまたいで持続するオリジンの新たな状態を導入するか？

   いいえ。

4. この仕様は、永続的なクロスオリジン状態を Web に公開するか？

   いいえ。

5. この仕様は、オリジンが現在アクセスできないその他のデータを公開するか？

   いいえ。

6. この仕様は、新しいスクリプト実行／読み込み機構を有効にするか？

   いいえ。

7. この仕様は、オリジンがユーザーの位置情報にアクセスすることを許可するか？

   いいえ。

8. この仕様は、オリジンがユーザーのデバイス上のセンサーにアクセスすることを許可するか？

   いいえ。

9. この仕様は、オリジンがユーザーのローカルコンピューティング環境の側面にアクセスすることを許可するか？

   いいえ。

10. この仕様は、オリジンが他のデバイスにアクセスすることを許可するか？

    いいえ。

11. この仕様は、オリジンにユーザーエージェントのネイティブ UI への何らかの制御を許可するか？

    いいえ。

12. この仕様は一時的な識別子を Web に公開するか？

    いいえ。

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

    いいえ。

14. この仕様はユーザーエージェントの “incognito” モードの文脈でどのように動作すべきか？

    違いはない。

15. この仕様はユーザーのローカルデバイスにデータを永続化するか？

    いいえ。

16. この仕様には “Security Considerations” および “Privacy Considerations” セクションがあるか？

    はい。

17. この仕様は既定のセキュリティ特性を低下させることを許可するか？

    いいえ。