CSS Display Module Level 3

1. 序論

この節は規範的である。 ◎ This section is normative.

~CSSは、いくつかの［ `要素@ , `~text~node@ ］が成す `木@ （ `tree^en ）として組織化されている~source文書を（ ~screen／紙／音声~streamなどとして） `~canvas$上に具現化する（ `render^en する — ~~描画する, ~~音声化する, 等々）。 これを行うため、 `~box木@ と呼ばれる中間~構造を生成する。 それは、具現化される文書の整形~構造を表現する。 `~box木$を成す各 `~box@ は、対応する`要素$（または`疑似要素$）を~canvas上の空間や時間において表現する。 同様に，`~box木$を成す各 `~text連なり@ （ `text run^en ）は、対応する`~text~node$たちの内容を表現する。 ◎ CSS takes a source document, organized as a tree of elements and text nodes, and renders it onto a canvas (such as your screen, a piece of paper, or an audio stream). To do this, it generates an intermediary structure, the box tree, which represents the formatting structure of the rendered document. Each box in the box tree represents its corresponding element (or pseudo-element) in space and/or time on the canvas, while each text run in the box tree likewise represents the contents of its corresponding text nodes.

~CSSは，`~box木$を作成するに先立って、先ず ~cascadingと継承 を利用して，~source木~内の各［ `要素$／`~text~node$ ］の各~CSS~propに`算出値$をあてがう（ `CSS3-CASCADE$r を見よ）。 ◎ To create the box tree, CSS first uses cascading and inheritance, to assign a computed value for each CSS property to each element and text node in the source tree. (See [CSS3-CASCADE].)

次に、各`要素$に対し，その `display$p ~propの指定値に従って， 0 個以上の`~box$を生成する。 要素から生成される`~box$は，概して一つだけだが、一部の `display$p 値（例： `list-item$v ）は 複数の~box（例： `主要~box$と`~marker~box$ ）を生成させる。 一部の値（ `none$v, `contents$v など）は、`要素$やその子孫に全く`~box$を生成させなくする。 `~box$は、その `display$p 型により言及されることが多い — 例えば `display:block$p にされた要素により生成される`~box$は、 “塊~box” または単に “塊” とも呼ばれる。 ◎ Then, for each element, CSS generates zero or more boxes as specified by that element’s display property. Typically, an element generates a single box. However, some display values (e.g. display: list-item) generate more than one box (e.g. a principal block box and a marker box). And some values (such as none or contents) cause the element and/or its descendants to not generate any boxes at all. Boxes are often referred to by their display type—e.g. a box generated by an element with display: block is called a “block box” or just a “block”.

他が指示されない限り、`~box$には，それを生成した`要素$と同じ~styleがあてがわれる。 一般に，`継承される~prop$は、`主要~box$にあてがわれてから，`~box木$を通して同じ要素が生成する他のすべての~boxに継承される。 継承されない~propは、既定では`主要~box$に適用されるが、要素が複数の~boxを生成するときには，異なる~boxに適用するよう定義されることもある： 例えば，~table要素に適用される `border$p ~propは、その`主要~box$である`~table包装~box$ではなく， `~table~box$に適用される。 値の算出~処理がそれらの~boxの~styleを改めていて，当の要素の~styleが要請された場合（ `getComputedStyle()$c などを通して）、その要素は，各~propごとに，その~propが適用された~boxからの値を反映する。 ◎ A box is assigned the same styles as its generating element, unless otherwise indicated. In general, inherited properties are assigned to the principal box, and then inherit through the box tree to any other boxes generated by the same element. Non-inherited properties default to applying to the principal box, but when the element generates multiple boxes, are sometimes defined to apply to a different box: for example, the border properties applied to a table element are applied to its table box, not to its principal table wrapper box. If the value computation process alters the styles of those boxes, and the element’s style is requested (such as through getComputedStyle()), the element reflects, for each property, the value from the box to which that property was applied.

同様に，各［ 互いに同胞かつ連続している，一連の`~text~node$ ］は、その~text内容を包含する`~text連なり$を生成し，それを生成している`~text~node$たちと同じ~styleがあてがわれる。 ただし，包含する~textが無い場合、`~text連なり$は生成されない。 ◎ Similarly, each contiguous sequence of sibling text nodes generates a text run containing their text contents, which is assigned the same styles as the generating text nodes. If the sequence contains no text, however, it does not generate a text run.

`匿名~box@ （ `anonymous box^en ）とは、どの要素にも結付けられていない~boxである。 `匿名~box$は、［ 特定0の入子~構造が要求されている状況下で，それが`要素~木$から生成される~boxたちから供されていないとき ］に，`~box木$を修復するために生成される。 例えば，`~table~cell~box$は、特定0の型の親~box（`~table~row~box$）を要求する。 その親が`~table~row~box$でない場合、自身の周りに`匿名の$`~table~row~box$を生成することになる（ `CSS2$r 17.2.1 節 を見よ）。 要素から生成される~boxは，その~styleを厳密に要素~木を通して継承するが、（`~box木$にのみ存在する）匿名~boxは，`~box木$の親子関係を通して~styleを継承する。 ◎ An anonymous box is a box that is not associated with any element. Anonymous boxes are generated in certain circumstances to fix up the box tree when it requires a particular nested structure that is not provided by the boxes generated from the element tree. For example, a table cell box requires a particular type of parent box (the table row box), and will generate an anonymous table row box around itself if its parent is not a table row box. (See [CSS2] § 17.2.1.) Unlike element-generated boxes, whose styles inherit strictly through the element tree, anonymous boxes (which only exist in the box tree) inherit through their box tree parentage.

`~box$や`~text連なり$は、~layoutに伴って，複数の`断片$に分断されることもある。 これは例えば、［ `行内~box$や`~text連なり$ ］が何~行lかに分断されるときや, `塊~box$が何個かの［ `頁~box$／`柱~box$ ］に分断されるときに起こる。 したがって、`~box$は 1 個以上の`~box断片$からなり，`~text連なり$は 1 個以上の~text`断片$からなる。 `断片化$についての更なる情報は、 `CSS3-BREAK$r を見よ。 ◎ In the course of layout, boxes and text runs can be broken into multiple fragments. This happens, for example, when an inline box and/or text run is broken across lines, or when a block box is broken across pages or columns. A box therefore consists of one or more box fragments, and a text run consists of one or more text fragments. See [CSS3-BREAK] for more information on fragmentation.

注記： ~CSS仕様には，ここに挙げる用語が固まる前に書かれていたり, 正しい用語を指していないものもあるので、これらの用語を利用している古い仕様を読むときは，注意するように。 それらが本当はどの用語を意味するかは，文脈から推定できるべきである。 仕様に誤りを見つけた方は、正されるように， 報告されたし。 ◎ Note: Many of the CSS specs were written before this terminology was ironed out, or refer to things incorrectly, so view older specs with caution when they’re using these terms. It should be possible to infer from context which term they really mean. Please report errors in specs when you find them, so they can be corrected.

注記： “聴覚” ~box木についての更なる情報と その `display$p ~propとの相互作用については、 CSS Speech Module にて見られる。 `CSS-SPEECH-1$r ◎ Note: Further information on the “aural” box tree and its interaction with the display property can be found in the CSS Speech Module. [CSS-SPEECH-1]

2. ~boxの~layout~mode： `display^p ~prop

~UAには、視覚的でないものも含む すべての媒体~上で，この~propを~supportすることが期待される。 ◎ User Agents are expected to support this property on all media, including non-visual ones.

`display$p ~propは、要素の `表示型@ （ `display type^en ）を定義する。 表示型は、要素がどのような~boxを生成するかについての，二つの基本的性質からなる： ◎ The display property defines an element’s display type, which consists of the two basic qualities of how an element generates boxes:

`内縁~表示型@

（`置換され$ない）要素が生成する`整形~文脈$の種類を定義し，その子孫~boxをどう~lay-outするかを~~指示する。 （`置換され$る要素の内縁~表示型は、~CSSの視野~外である。） ◎ the inner display type, which defines (if it is a non-replaced element) the kind of formatting context it generates, dictating how its descendant boxes are laid out. (The inner display of a replaced element is outside the scope of CSS.)

【“〜~layout” と記されたときは、概ね，この表示型を指している。】

`外縁~表示型@

要素が生成する`主要~box$自身が`~flow~layout$にどう関与するかを規定する。 ◎ the outer display type, which dictates how the principal box itself participates in flow layout.

【“［行内／塊］~levelの~box（あるいは要素, 内容）” と記されたときは、この表示型を指している。】

`~text連なり$には、`表示型$は無い。 ◎ Text runs have no display type.

一部の `display$p 値には、追加の副作用が伴われる： 例えば `list-item$v は `marker$pe 疑似要素も生成し， `none$v は 要素の部分木をまるごと~box木から外す。 ◎ Some display values have additional side-effects: such as list-item, which also generates a ::marker pseudo-element, and none, which causes the element’s entire subtree to be left out of the box tree.

`display$p ~propによる要素の意味論に対する効果は無い。 意味論は、`文書~言語$により定義され，~CSSからは影響されない。 `none$v 値は別として（それは、聴覚／発話 `CSS-SPEECH-1$r の出力や，要素, その子孫の対話性にも影響する）、 `display$p ~propが影響するのは，視覚~layoutに限られる。 その目的は、［ 下層~文書の意味論に影響することなく 要素の~layoutの挙動を変更する ］自由を，設計者に与えることである。 ◎ The display property has no effect on an element’s semantics: these are defined by the document language and are not affected by CSS. Aside from the none value, which also affects the aural/speech output [CSS-SPEECH-1] and interactivity of an element and its descendants, the display property only affects visual layout: its purpose is to allow designers freedom to change the layout behavior of an element without affecting the underlying document semantics.

各種 値は、次のように定義される： ◎ Values are defined as follows:

`display-outside@t
    = `block$v
    | `inline$v
    | `run-in$v ;

`display-inside@t
    = `flow$v
    | `flow-root$v
    | `table$v
    | `flex$v
    | `grid$v
    | `ruby$v ;

`display-listitem@t
    = `display-outside$t? && [ `flow$v | `flow-root$v ]? && `list-item$v ;

`display-internal@t
    = `table-row-group$v
    | `table-header-group$v
    | `table-footer-group$v
    | `table-row$v
    | `table-cell$v
    | `table-column-group$v
    | `table-column$v
    | `table-caption$v
    | `ruby-base$v
    | `ruby-text$v
    | `ruby-base-container$v
    | `ruby-text-container$v ;

`display-box@t
    = `contents$v
    | `none$v ;

`display-legacy@t
    = `inline-block$v
    | `inline-table$v
    | `inline-flex$v
    | `inline-grid$v ;

次の一覧（参考）に，各種 `display$p 値を要約する： ◎ The following informative table summarizes the values of display:

注記： 等価な `display$p 値の直列化においては、 “最も後方互換, 次に最短” による優先順位に~~則って， “短い~~表記” の列を利用する `CSSOM$r ◎ Note: Following the precedence rules of “most backwards-compatible, then shortest”, serialization of equivalent display values uses the “Short display” column. [CSSOM]

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

`block$v box
└匿名 `table$v box
 └匿名 `table-row-group$v box
  └匿名 `table-row$v box
   └`table-cell$v box

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

`table$v box
└匿名 `table-row-group$v box
 └`table-row$v box
  └`table-cell$v box

3. 同行見出し~layout

`同行見出し~box@ （ `run-in box^en ）とは、後続の塊に併合されるような~boxである — ~boxは塊の行内level内容の先頭に挿入される。 これは、短い表題や定義語の類いを整形するとき — DOM 構造においては，表題は 後続の注釈文より先行する方が適切でありつつ、表示においては，~textと伴に 行内levelの表題として~lay-outする方が欲されるとき — に有用になる。 ◎ A run-in box is a box that merges into a block that comes after it, inserting itself at the beginning of that block’s inline-level content. This is useful for formatting compact headlines, definitions, and other similar things, where the appropriate DOM structure is to have a headline preceding the following prose, but the desired display is an inline headline laying out with the text.

<dl class='dict'>
  <dt>パラドクス
  <dd>~~一般に容認される前提から、反駁し難い推論によって、~~一般に容認し難い結論を導く論説。逆理。
  <dt>ジレンマ
  <dd>前提を受け入れると、二つの選択肢の導く結論がともに受け入れ難いものになること。両刀論法。
</dl>
<style>
.dict > dt {
  display: run-in;
}
.dict > dt::after {
  content: "："
}
</style>

パラドクス：~~一般に容認される前提から、反駁し難い推論によって、~~一般に容認し難い結論を導く論説。逆理。

ジレンマ：前提を受け入れると、二つの選択肢の導く結論がともに受け入れ難いものになること。両刀論法。

`同行見出し~box$の挙動は、次を除き，他の`行内level~box$と同じになる： ◎ A run-in box behaves exactly as any other inline-level box, except:

• `内縁~表示型$が `flow$v にされた`同行見出し~box$は、その内容を`行内~化$する。 ◎ A run-in box with a flow inner display type inlinifies its contents.

• `同行見出し列$の直後に［ 新たな`塊~整形~文脈$を確立しない`塊~box$ ］が来る場合、その列は `塊~box$に直の子として挿入される — 挿入-箇所は、 `marker$pe 疑似要素が生成する~box（もし在れば）より後, かつ 塊の内容が生成する 他の~box（ `before$pe 疑似要素も含む）より前になる。 この親を違える~~処理は、アリなら再帰的に行われる（同行見出しが、実質的に，その整形~文脈における最も深い後続の “段落” の一部になるように — 他の同行見出しが新たに隣接するようになったなら，それらを収集しながら）。 ◎ If a run-in sequence is immediately followed by a block box that does not establish a new block formatting context, it is inserted as direct children of the block box after its ::marker pseudo-element’s boxes (if any), but preceding any other boxes generated by the contents of the block (including the box generated by the ::before pseudo-element, if any). This re-parenting recurses if possible (so that the run-in effectively becomes part of the deepest subsequent “paragraph” in its formatting context, collecting newly-adjacent run-ins as it goes).

  次に，~layout上の親が違えられた内容は、元の親がそこに在るかのように整形される。 注記： ~layout上の親子関係のみが影響され, 継承関係は影響されない — 匿名でない~boxに対する~propの継承関係は要素~木に基づくので。 ◎ The reparented content is then formatted as if originally parented there. Note that only layout is affected, not inheritance, because property inheritance for non-anonymous boxes is based only on the element tree.

• 他の場合（`同行見出し列$にそのような塊は後続しない場合）、［ `同行見出し列$と,［ その直後から連続する すべての行内level内容 — ただし，次の`同行見出し列$が在れば その手前まで ］］の周囲に，匿名`塊~box$が生成される。 ◎ Otherwise (if the run-in sequence is not followed by such a block), an anonymous block box is generated around the run-in sequence and all immediately following inline-level content (up to, but not including, the next run-in sequence, if any).

`同行見出し列@ とは、互いに同胞の`同行見出し~box$からなる，連続する（ただし，`空白$や`~flow外$にある~boxが挟まれてもよい）最長の並びである。 ◎ A run-in sequence is a maximal sequence of consecutive sibling run-in boxes and intervening white space and/or out-of-flow boxes.

注記： このことは、`~flow外$にある~boxは、 2 個の `run-in^v ~boxの間に挟まれている場合には，~layout上の親が違えられることを含意する。 この案は，多少無作為に選び取られており、他にも，挟まれている~flow外の~boxは後ろに回す案や、それに先行する `run-in^v ~boxが同行見出しになるのを妨げる案もある。 実装者と作者には、選好する挙動があれば CSSWG に伝えることが奨励される。 ◎ Note: This statement implies that out-of-flow boxes are reparented if they are between two run-in boxes. Another alternative would be to leave behind the intervening out-of-flow boxes, or to have out-of-flow boxes impede the running-in of earlier boxes. Implementers and authors are encouraged to contact the CSSWG if they have a preferred behavior, as this one was picked somewhat at random.

この修復は、 CSS2, 9.2 節 に述べられる，匿名~塊と行内~boxの修復の前に生じ、影響される要素の`整形される最初の行l$の決定に影響する — `同行見出し列$が、~box木におけるその最終的な所在に，元からあったかのように。 ◎ This fixup occurs before the anonymous block and inline box fixup described in CSS2§9.2, and affects the determination of the first formatted line of the affected elements as if the run-in sequence were originally in its final location in the box tree.

注記： 先頭に来る同行見出しは，その包含塊の`整形される最初の行l$上の最初の~textを表現するので、その塊~要素に適用される `first-letter$pe 疑似要素は、自前の内容の先頭字（ `first letter^en ）ではなく，その同行見出しの先頭字を選択する。 ◎ Note: As the earliest run-in represents the first text on the first formatted line of its containing block, a ::first-letter pseudo-element applied to that block element selects the first letter of the run-in, rather than the first letter of its own contents.

注記： この同行見出し~modelは、以前の `CSS2$r 改訂版にて提案されたものから 少しばかり異なる。 ◎ Note: This run-in model is slightly different from the one proposed in earlier revisions of [CSS2].

付録 A. 用語集

便宜を図るため、以下の用語を，ここに定義する： ◎ The following terms are defined here for convenience:

`主要~box@ （ `principal box^en ）

`要素$が 1 個~以上の`~box$を生成するとき、それらのうち 1 つが`主要~box$になる。 それは、要素の［ 子孫~boxたち, 生成ed内容 ］を包含し，位置決め~schemeがあればそれに孕まれる。 ◎ When an element generates one or more boxes, one of them is the principal box, which contains its descendant boxes and generated content, and is also the box involved in any positioning scheme.

要素には、主要~boxの他にも追加の~boxたちを生成するものもある（例： `list-item$v 要素は，追加の~marker~boxを生成する ／ また， `table$v 要素は、`主要~box$として`~table包装~box$を生成することに加え，追加の`~table~box$も生成する）。 これらの追加の~boxは、主要~boxに~~相対的に配置される。 ◎ Some elements may generate additional boxes in addition to the principal box (such as list-item elements, which generate an additional marker box, or table elements, which generate a principal table wrapper box and an additional table box). These additional boxes are placed with respect to the principal box.

`行内level@ （ `inline-level^en ）

行内~layoutに関与する内容。 特定的には、`行内level~box$, `~text連なり$。 ◎ Content that participates in inline layout. Specifically, inline-level boxes and text runs.

【 “〜に関与する（ `participate^en ）” ： 生成される~boxが、［ 当の種別（ここでは，種別 “行内” ）であるような，`整形~文脈$ ］の一部を成していて，その種別の~layout規則に則って~layoutされることを意味する。 （整形~文脈を確立している~box（整形~文脈の根）自身は、自身が確立した整形~文脈に “関与する” とは言わない — それが関与するのは、親の整形~文脈になる。） 】【 “X ~levelの Y” ／ “Y は X ~levelである” の様な句（ Y は~boxまたは要素）は、 Y の外（例えば， Y が関与している`整形~文脈$）からは， Y は X であるかのように見える／扱われることを表す（ “~level” という語は、外に対する関係を含意する）。 】

`塊level@ （ `block-level^en ）

塊~layoutに関与する内容。 特定的には、`塊level~box$。 ◎ Content that participates in block layout. Specifically, block-level boxes.

`行内~box@ （ `inline box^en ）【 “可分な行内（ `non-atomic inline^en ）” 】

`行内level$の~boxのうち，［ `内縁~表示型$は `flow$v である, かつ`置換され$ない ］もの。 `行内~box$の内容は，~box自身と同じ`行内~整形~文脈$に関与する。 ◎ A non-replaced inline-level box whose inner display type is flow. The contents of an inline box participate in the same inline formatting context as the inline box itself.

`行内@ （ `inline^en ）

多義的にならない所で、［ `行内~box$, `行内level~box$ ］いずれかの略語として用いられる。 形容詞として`行内level$の意味でも用いられるが†、この用法は非推奨にされた。 ◎ Used as a shorthand for inline box or inline-level box where unambiguous, or as an adjective meaning inline-level. The latter usage is deprecated.

【 ここに述べたように，よく似た／多義的にも見える用語がいくつかある。 】【† 例えば、 “行内~内容”, “行内~要素” など， “行内” がどちらを意味するのか自明でないこともあり、ときには，仕様にも誤用がある（実に紛らわしい）。 】

`不可分な行内@ （ `atomic inline^en ）

`行内level$の~boxのうち，［ `置換され$る（画像など）, または 新たな`整形~文脈$を確立する（ `inline-block$v や `inline-table$v など ） ］もの。 （`行内~box$や`~ruby容器$のように）複数~行lに分割されることはない。 ◎ An inline-level box that is replaced (such as an image) or that establishes a new formatting context (such as an inline-block or inline-table) and cannot split across lines (as inline boxes and ruby containers can).

`内縁~表示型$が `flow$v でない 行内level~boxは、指定された`内縁~表示型$による新たな`整形~文脈$を確立する。 ◎ Any inline-level box whose inner display type is not flow establishes a new formatting context of the specified inner display type.

【 すなわち，`行内level$の~boxは、二つの類型［ `行内~box$, `不可分な行内$ ］に，排他的に分類される — `行内~box$の意味で用いられる “行内” は、実際には “可分な” （ “不可分な” の否定）が省略されている。 】【 “置換される” は、その内容の整形が~CSSの外で定義されるので， “新たな（未知の）整形~文脈を確立するようなもの” と解釈できる — この解釈の下では、［ （可分な）行内／不可分な行内 ］の分類は、新たな整形~文脈を［ 確立しない／確立する ］に捉え直すことができる。 】

`塊~容器@ （ `block container^en ）

塊~容器は、`行内~整形~文脈$に関与する行内level~boxのみを包含するか, または `塊~整形~文脈$に関与する塊level~boxのみを包含する（場合によっては、この拘束を確保するため，匿名~塊~boxを生成した上で） — `CSS2$r の 9.2.1.1 節 にて定義されるように。 ◎ A block container either contains only inline-level boxes participating in an inline formatting context, or contains only block-level boxes participating in a block formatting context (possibly generating anonymous block boxes to ensure this constraint, as defined in CSS2§9.2.1.1).

【 内容が空でも、塊~容器になり得る（ 0 個の~box “のみ” を包含する）。 】

行内levelの内容のみを包含する塊~容器は、新たな`行内~整形~文脈$を確立する。 そのような要素は、自身の行内~内容すべてを包装する，`根~行内~box$も生成する。 注記： この`根~行内~box$の概念は、実質的に， `CSS2$r の同じ節 9.2.2.1 節 にて導入された “匿名~行内~要素” の概念を置換する。 ◎ A block container that contains only inline-level content establishes a new inline formatting context. The element then also generates a root inline box which wraps all of its inline content. Note, this root inline box concept effectively replaces the "anonymous inline element" concept introduced in CSS2§9.2.2.1.

塊~容器は、親の整形~文脈は`塊~整形~文脈$でないならば，新たな`塊~整形~文脈$を確立する。 他の場合，すなわち`塊~整形~文脈$に関与しているならば、自身の内容に対し新たな`塊~整形~文脈$を確立するか，ただ関与するものであり続ける — どちらになるかは、他の~prop（ `overflow$p や `align-content$p など）による拘束により決定される。 ◎ A block container establishes a new block formatting context if its parent formatting context is not a block formatting context; otherwise, when participating in a block formatting context itself, it either establishes a new block formatting context for its contents or continues the one in which it participates, as determined by the constraints of other properties (such as overflow or align-content).

注記： 塊~容器~boxは、塊~整形~文脈と行内~整形~文脈を同時に確立することもある。 ◎ Note: A block container box can both establish a block formatting context and an inline formatting context simultaneously.

`塊~box@ （ `block box^en ）

`塊~容器$であって，`塊level~box$でもあるもの。 ◎ A block-level box that is also a block container.

【 言い換えれば、`塊~整形~文脈$に関与する~boxのうち，［ 行内~整形~文脈~以外の整形~文脈 ］は確立しないもの。 】

注記： `塊~容器~box$であっても，`塊level~box$になるとは限らない。 例えば，置換されない［ 行内~塊 ／~table~cell ］は、塊~容器であるが，塊level~boxではない。 同様に、`塊level~box$であっても，`塊~容器~box$になるとは限らない。 例えば，［ 塊levelの置換~要素（ `display:block$p ）／ `~flex容器$（ `display:flex$p ） ］は塊~容器でない。 ◎ Note: Not all block container boxes are block-level boxes: non-replaced inline blocks and non-replaced table cells, for example, are block containers but not block-level boxes. Similarly, not all block-level boxes are block containers: block-level replaced elements (display: block) and flex containers (display: flex), for example, are not block containers.

`塊@ （ `block^en ）

多義的にならない所で、［ `塊~box$, `塊level~box$, `塊~容器~box$ ］いずれかの略語として用いられる。 ◎ Used as a shorthand for block box, block-level box, or block container box, where unambiguous.

`置換~要素@ （置換される要素, `replaced element^en ）

要素のうち，その内容は~CSS整形~modelの視野~外にあるもの — 画像, 埋込みの文書など。 例えば~HTML `img$e 要素の内容は、その `src$a 属性が指す画像に置換されることが多い。 置換~要素は、内在的~寸法 — 内在的~横幅, 内在的~縦幅, 内在的~縦横比 — を持つことが多い。 例えば、内在的［ 横幅, 縦幅 ］が絶対~単位で指定された~bitmap画像（内在的~縦横比も，それらから自明に決定できる）。 他方、内在的~寸法を持たない文書もある（例えば空内容の~HTML文書）。 ◎ An element whose content is outside the scope of the CSS formatting model, such as an image or embedded document. For example, the content of the HTML img element is often replaced by the image that its src attribute designates. Replaced elements often have intrinsic dimensions: an intrinsic width, an intrinsic height, and an intrinsic ratio. For example, a bitmap image has an intrinsic width and an intrinsic height specified in absolute units (from which the intrinsic ratio can obviously be determined). On the other hand, other documents may not have any intrinsic dimensions (for example, a blank HTML document).

~UAは、置換~要素の内在的~寸法を通して敏感な情報が第三者主体に漏洩され得ると予見される場合には、内在的~寸法を持たないものと見なしてよい。 例えば~HTML文書において，利用者の預金残高に依存して内在的~sizeが変化する場合、~UAは，その資源は内在的~寸法を持たないかのように動作するよう求められるかもしれない。 ◎ User agents may consider a replaced element to not have any intrinsic dimensions if it is believed that those dimensions could leak sensitive information to a third party. For example, if an HTML document changed intrinsic size depending on the user’s bank balance, then the UA might want to act as if that resource had no intrinsic dimensions.

置換~要素の内容は、~CSS整形~modelの外にあると見なされる。 しかしながら、その内在的~寸法は，様々な~layout計算に利用される。 ◎ The content of replaced elements is not considered in the CSS formatting model; however, their intrinsic dimensions are used in various layout calculations.

`置換され$ない要素（ “`置換され$る” の否定）は、 `非~置換@ 要素とも称される — すなわち、その具現化は~CSS~modelにより規定される。 【和訳では、単に`置換され$ないと記すことが多い。】 ◎ A non-replaced element is one that is not replaced, i.e. whose rendering is dictated by the CSS model.

`包含塊@ （ `containing block^en ）

結付けられている一連の~box（通例，包含塊を生成した~boxの一連の子になる）の［ ~sizeや位置 ］を決める際の基準とされる矩形†。 包含塊は、~boxではないことに注意（それは矩形である） — しかしながら、多くの場合，【それを生成する】~boxの寸法から導出される。 包含塊に対する~prop値は，その包含塊を生成した~boxの~prop値を指す（`初期~包含塊$用には，根~要素から値が採られる）。 詳細は `CSS2$r 9.1.2 節, 10.1 節 に。 ◎ A rectangle that forms the basis of sizing and positioning for the boxes associated with it (usually the children of the box that generated it). Notably, a containing block is not a box (it is a rectangle), however it is often derived from the dimensions of a box. If properties of a containing block are referenced, they reference the values on the box that generated the containing block. (For the initial containing block, the values are taken from the root element.) See [CSS2] Section 9.1.2 and Section 10.1 for details.

【† 実質的には、内容を~lay-outするための座標系と捉えられる。 】

【 “要素の包含塊” という句の “~~包含（ `containing^en ）” は、要素が生成する~boxを 包含している ことを表す（要素が生成する~boxから導出されるものではなく、通例的には，要素のいずれかの先祖が生成する~boxから導出される）。 】

`包含塊~連鎖@（ `containing block chain^en ）

`包含塊$の関係を通して［ 先祖 ↔ 子孫 ］の連鎖を形成する，`包含塊$の連列。 例えば、`行内~box$ B の包含塊は， B に最も近い先祖の`塊~容器$ C の内容~boxになる。 C が`~flow内$にある`塊$であるならば、 C の包含塊は， C の親である`塊~容器$ C1 により形成される。 親の親である C1 が絶対位置されているならば、 C1 の包含塊は C1 に最も近い有位置な先祖（ C1 の親になるとは限らない）の~padding辺からなる, 等々。 以下同様に、`初期~包含塊$に達するまで連鎖は続く。 ◎ A sequence of successive containing blocks that form an ancestor-descendant chain through the containing block relation. For example, an inline box’s containing block is the content box of its closest block container ancestor; if that block container is an in-flow block, then its containing block is formed by its parent block container; if that grandparent block container is absolutely positioned, then its containing block is the padding edges of its closest positioned ancestor (not necessarily its parent), and so on up to the initial containing block.

`初期~包含塊@ （ `initial containing block^en ）

根~要素の`包含塊$。 連続的~媒体~用のそれは `CSS2$r 10.1 節 にて，頁媒体~用のそれは `CSS3PAGE$r にて定義される。 ◎ The containing block of the root element. See CSS2.1§10.1 for continuous media; and [CSS3PAGE] for paged media.

`整形~文脈@ （ `formatting context^en ）

関係する~boxたちを~lay-outするための環境。 ~lay-outするための規則は、`整形~文脈$の型ごとに異なる。 例えば、`~flex整形~文脈$ `CSS3-FLEXBOX$r は，`~flex~layout$規則に則って~boxたちを~lay-outする一方で、`塊~整形~文脈$ `CSS2$r は，~boxたちを `塊＆行内~layout$規則に則って~lay-outする。 加えて，一部の型の`整形~文脈$たちは、互いに差挟まれたり共存することもある。 例えば，`行内~整形~文脈$は、それを確立した要素が関与している`塊~整形~文脈$の中にあり，それと相互作用する。 また，`~ruby容器$は、その`~ruby基底~容器$が関与している`行内~整形~文脈$越しに`~ruby整形~文脈$を重層する。 ◎ A formatting context is the environment into which a set of related boxes are laid out. Different formatting contexts lay out their boxes according to different rules. For example, a flex formatting context lays out boxes according to the flex layout rules [CSS3-FLEXBOX], whereas a block formatting context lays out boxes according to the block-and-inline layout rules [CSS2]. Additionally, some types of formatting contexts interleave and co-exist: for example, an inline formatting context exists within and interacts with the block formatting context of the element that establishes it, and a ruby container overlays a ruby formatting context over the inline formatting context in which its ruby base container participates.

~boxは、新たな`独立な整形~文脈$を確立するか，自身の包含塊の`整形~文脈$を継続する。 一部の事例では、それに加えて，他と共存する（独立でない）新たな整形~文脈を確立する。 しかしながら，他が指定されない限り、新たな`整形~文脈$を確立したときには，`独立な整形~文脈$を作成する。 ~boxにより確立される整形~文脈の型は、~boxの`内縁~表示型$により決定される。 例えば： `格子~容器$は 新たな`格子~整形~文脈$を確立する ／ `~ruby容器$は 新たな`~ruby整形~文脈$を確立する ／ `塊~容器$は 新たな［ `塊~整形~文脈$／`行内~整形~文脈$ ］を確立し得る。 `display$p ~propを見よ。 ◎ A box either establishes a new independent formatting context or continues the formatting context of its containing block. In some cases, it might additionally establish a new (non-independent) co-existing formatting context. Unless otherwise specified, however, establishing a new formatting context creates an independent formatting context. The type of formatting context established by the box is determined by its inner display type. E.g. a grid container establishes a new grid formatting context, a ruby container establishes a new ruby formatting context, and a block container can establish a new block formatting context and/or a new inline formatting context. See the display property.

`独立な整形~文脈@

~boxが独立な整形~文脈を確立するときは、本質的に，他と独立な~layout環境を新たに作成する（自身の親の`整形~文脈$と同じ型かどうかに関わらず）： 一般に、~box自身の~sizingによるものを除いて、その子孫の~layoutは，~boxの外側の`整形~文脈$による規則や内容からは影響されず, その逆も同様になる。 ◎ When a box establishes an independent formatting context (whether that formatting context is of the same type as its parent or not), it essentially creates a new, independent layout environment: except through the sizing of the box itself, the layout of its descendants is (generally) not affected by the the rules and contents of the formatting context outside the box, and vice versa.

【 言い換えれば，独立な整形~文脈は、`~box木$の中で［ それを確立している~boxを根とする部分木 ］が成す内容から，［ 新たに別の独立な整形~文脈を確立するような各 子孫~box ］の内容すべてを除いた部分を表現する。 】

例えば，`塊~整形~文脈$の中の浮動体（浮動される~box）は、周囲の~boxの~layoutに影響するが，その効果が その`整形~文脈$の外へ~~波及することはない： その`整形~文脈$を確立している~boxは、浮動体を全部的に包含するように大きくされ，その~boxの外側の浮動体が［ ~box内に突き出たり，~boxの内側の内容に影響する ］ことは許容されない。 ◎ For example, in a block formatting context, floated boxes affect the layout of surrounding boxes. But their effects do not escape their formatting context: the box establishing their formatting context grows to fully contain them, and floats from outside that box are not allowed to protrude into and affect the contents inside the box.

別の例として，~marginは、`整形~文脈$の境界をまたがって相殺されることはない。 ◎ As another example, margins do not collapse across formatting context boundaries.

注記： `排他~box$ `CSS3-EXCLUSIONS$r は、`独立な整形~文脈$の境界を超えて内容に影響できる（この仕様を書いている時点では、そのような~layout特色機能は，これに限られる）。 ◎ Exclusions are able to affect content across independent formatting context boundaries. (At time of writing, they are the only layout feature that can.) [CSS3-EXCLUSIONS]

ある種の~propは、普通でなくなる事例では，~boxに `独立な整形~文脈を確立-@ させるよう強制する。 例えば，`~flow外$にされた~boxは、`塊~化$されるに伴い，`独立な整形~文脈を確立-$するようになる。 別の例として、 `contain$p ~propのある種の値は，~boxに`独立な整形~文脈を確立-$させる。 塊を`~scroll容器$に転換することは、それに`独立な整形~文脈を確立-$させることになる — しかしながら，`下位格子$を`~scroll容器$に転換しても そうはならず、下位格子として動作し続け，その内容は親の`格子~容器$の~layoutに関与し続ける。 ◎ Certain properties can force a box to establish an independent formatting context in cases where it wouldn’t ordinarily. For example, making a box out-of-flow causes it to blockify as well as to establish an independent formatting context. As another example, certain values of the contain property can cause a box to establish an independent formatting context. Turning a block into a scroll container will cause it to establish an independent formatting context; however turning a subgrid into a scroll container will not—it continues to act as a subgrid, with its contents participating in the layout of its parent grid container.

`独立な整形~文脈を確立-$する`塊~box$は、自身の内容~用に新たな`塊~整形~文脈$を確立する。 他のほとんどの事例では、~boxに`独立な整形~文脈を確立-$させようと強制しても，何も起きない — ~boxはすでに`独立な整形~文脈$を確立しているか（例：`~flex容器$），その型の~box上に全く独立な新たな整形~文脈を確立することはアリでない（例：置換されない`行内~box$）。 ◎ A block box that establishes an independent formatting context establishes a new block formatting context for its contents. In most other cases, forcing a box to establish an independent formatting context is a no-op—either the box already establishes an independent formatting context (e.g. flex containers), or it’s not possible to establish a totally independent new formatting context on that type of box (e.g. non-replaced inline boxes).

`塊~整形~文脈@ （ `block formatting context^en ）

`行内~整形~文脈@ （ `inline formatting context^en ）

［ `塊~整形~文脈$／`行内~整形~文脈$ ］は CSS 2.1, 9.4 節 にて定義される。 `行内~整形~文脈$は、`塊~整形~文脈$の中に存在する（また、それを包含している`塊~整形~文脈$の一部を成す） — 例えば、`行内~整形~文脈$に属する行l~boxは、`塊~整形~文脈$に属する浮動体と相互作用する。 ◎ Block and inline formatting contexts are defined in CSS 2.1 Section 9.4. Inline formatting contexts exist within (are part of their containing) block formatting contexts; for example, line boxes belonging to the inline formatting context interact with floats belonging to the block formatting context.

`塊~整形~文脈~根@ （ `block formatting context root^en ）

`塊~容器~box$であって，新たな`塊~整形~文脈$を確立するもの。 ◎ A block container that establishes a new block formatting context.

`~BFC@

［ `塊~整形~文脈$, または `塊~整形~文脈~根$ ］の略称。 ［ 内部に浮動体を包含する／ 外部の浮動体を除外する／ ~margin相殺を抑止する ］ような~boxを指すときなど，種々の非公式的な定義があるため、特定的には次のいずれかを指し得る： ◎ Abbreviation for block formatting context or block formatting context root. Has various informal definitions referring to boxes which contain internal floats, exclude external floats, and suppress margin collapsing, and may therefore refer specifically to one of:

• `塊~容器~box$であって，自身の内容に対し新たな`塊~整形~文脈$を確立するもの。 ◎ a block container that establishes a new block formatting context for its contents
• `塊~box$（すなわち，`塊level$の塊~容器）であって，自身の内容に対し`塊~整形~文脈$を確立するもの（確立しない塊~boxと判別されるよう）。 ◎ a block box (i.e. a block-level block container) that establishes a block formatting context for its contents (as distinguished from a block box which does not)
• （ごく大雑把に、）`塊level~box$であって，（`行内~整形~文脈$以外の）新たな`整形~文脈$を確立するもの。 ◎ (very loosely) any block-level box that establishes a new formatting context (other than an inline formatting context)

`~flow外@ （ `out-of-flow^en ）

`~flow内@ （ `in-flow^en ）

~boxは、［ （ `float$p を介して）浮動されている ／ （ `position$p を介して）絶対位置されている ］ならば，`~flow外$にあるとされる。 `~flow外$にない~boxは、`~flow内$にあるとされる。 ◎ A box is out-of-flow if it is floated (via float) or absolutely-positioned (via position). A box is in-flow if it is not out-of-flow.

注記： `整形~文脈$によっては、要素の `float$p が非 `none^v にされていても`~flow外$になるとは限らないよう，浮動させなくする場合がある。 【例えば、格子~layout／~flex~layoutの中】 ◎ Note: some formatting contexts inhibit floating, so that an element with float: left is not necessarily out-of-flow.

`文書~順序@（ `document order^en, 略して “文書~順” ）

文書~内で，~boxや内容が生じる順序（具現化~用に現れる順序とは異なり得る）。 疑似要素たちの順序を決定する目的においては、`~box木$による順序が利用される — 木に留まる疑似要素 節 `CSS-PSEUDO-4$r を見よ。 ◎ The order in which boxes or content occurs in the document (which can be different from the order in which it appears for rendering). For the purpose of determining the relative order of pseudo-elements, the box-tree order is used, see CSS Pseudo-Elements 4 §4 Tree-Abiding Pseudo-elements.

これらの用語の全部的な定義については `CSS2$r 9 章 を見よ。 ◎ See [CSS2] Chapter 9 for a fuller definition of these terms.

付録 B. 非通例的~要素~上の `display:contents^p の効果

この節は、（現時点では）規範的でない。 ◎ This section is (currently) non-normative.

要素には、純粋に~CSS~boxの概念で具現化されないものもある。 例えば： 置換~要素（ `img$e など）, 多くの~form-control（ `input$e など）, ~SVG要素。 ◎ Some elements aren’t rendered purely by CSS box concepts; for example, replaced elements (such as img), many form controls (such as input), and SVG elements.

この付録は、 `display:contents$p が，それらにどう相互作用するかを定義する。 ◎ This appendix defines how they interact with display: contents.

付録 C. 仕様~策定者~向けの~box構築~指針

この節は、仕様~策定者~向けの規範的でない手引きである。 ◎ This section is non-normative guidance for specification authors.

• ~boxを`塊~化$すると同時に`行内~化$することは できない。 そのようになり得る場合、どっちになるか定義すること。 ◎ A box cannot be blockified and inlinified at the same time; if such a thing would occur, define which wins over the other.
• `塊~化$できるのは、`主要~box$か`匿名~box$に限られる： 塊~化は、要素の算出値に影響するので，その`主要~box$の型を決定する。 ◎ Non-principal non-anonymous boxes can’t be blockified: blockification affects the element’s computed values and thus determines the type of its principal box.
• 自身の内容を`塊~化$する~boxは、`行内level$の内容を直に包含できない。 そのような要素の中で生成されるどの［ ~box／~text連なり ］も，`塊~化$されるか, `匿名の$`塊~容器$内に包装され~MUST。 ◎ Boxes which blockify their contents can’t directly contain inline-level content; any boxes or text runs generated within such an element must be blockified or wrapped in an anonymous block container.
• 自身の内容を`行内~化$する~boxは、`塊level$の~boxを直に包含できない。 そのような要素の中で生成されるどの~boxも`行内level$で~MUST。 ◎ Boxes which inlinify their contents can’t directly contain block-level boxes; any boxes generated within such an element must be inline-level.
• ~boxのうち，根本的に`独立な整形~文脈$を確立できないもの（置換されない行内など）に`独立な整形~文脈を確立-$させようとしては~MUST_NOT。 その前に塊~化するか，あるいは その~box型を`独立な整形~文脈$を確立できるものに変更すること。 ◎ Boxes that fundamentally cannot establish an independent formatting context (such as non-replaced inlines) must not be asked to establish an independent formatting context. Blockify them first, or otherwise change their box type to one that can establish an independent formatting context.

謝辞

年月に渡り，~box生成における異質な詳細を~~分別しようと試みてきた 多くの方々に。 特に、目標達成には至らなかったが，現在の仕様の基礎になった， `Bert Bos^en 氏による `display-model^p, `display-role^p についての最後の試みに。 CSS2.1 の 9 章に対する~~容赦なき~~考査により，混沌から~~一定の秩序を導き出された `Anton Prowse^en 氏に。 この仕様における数多の繊細な区別と誤りを選り分けられた `Oriol Brufau^en 氏に。 ~feedbackを寄せられた、次の方々にも： ◎ We would like to thank the many people who have attempted to separate out the disparate details of box generation over the years, most particularly Bert Bos, whose last attempt with display-model and display-role didn’t get anywhere, but primed us for the current spec; Anton Prowse, whose relentless assault on CSS2.1 Chapter 9 forced some order out of the chaos; and Oriol Brufau, who teased apart dozens of fine distinctions and errors in this spec.＼

Honorable mentions also go to David Baron, Mats Palmgren, Ilya Streltsyn, and Boris Zbarsky for their feedback.

変更点

~commentの集積もある。 ◎ A Disposition of Comments is available.

2018 年 4 月 20 日 作業草案 からの変更点は： ◎ Changes since the 20 April 2018 Working Draft include:

• `display:contents$p にされた要素は、 `display:none^p として挙動するのではなく，今や `display:none^p に算出される。 `2755$issue ◎ Elements with display: contents that behave as display: none now compute to display: none. (Issue 2755)
• ある種の整形~文脈たちが成す層において、`独立な整形~文脈$と “新たな” `整形~文脈$とが判別されるようにした。 `2597$issue `1457$issue ◎ Distinguished “new” formatting context from independent formatting context since certain formatting contexts layer. (Issue 2597, Issue 15457)
• `独立な整形~文脈$を確立する`塊~box$上の `display$p の使用値は、基準点を供し易くするため， `flow-root$v になるものと定義した。 `1550$issue ◎ Defined that block boxes that establish an independent formatting context have a used display of flow-root, to provide an easier point of reference. (Issue 1550)
• `display$p は~animate可能でないことを明確化した（離散的に~animate可能ではなく）。 `2938$issue ◎ Clarified that display is not animatable (as opposed to discretely animatable). (Issue 2938)
• 編集上の細かい修正点。 ◎ Minor editorial fixes.

2017 年 7 月 20 日付 作業草案 からの変更点は： ◎ Changes since the 20 July 2017 Working Draft include:

• CSS2 との互換性を確保するため、［ `inline-block$v ／ `inline flow-root^v ］に対する`塊~化$用の規則を整備した。 `1246$issue — それに伴い、 `run-in flow-root^v の取扱いを合致するように更新した。 `1715$issue ◎ Tightened up rules for the blockification of inline-block / inline flow-root to ensure compatibility with CSS2. (Issue 1246) Updated handling of run-in flow-root to match. (Issue 1715)
• `display$p に対する `list-item$v ~keywordは最後に来るよう，文法を調整した。 これは、期待される直列化~順序に影響する。 `1621$issue ◎ Adjusted grammar of display to list the list-item keyword last. This affects the expected serialization order. (Issue 1621)
• 行内~整形~文脈を確立している塊~容器~内での［ `塊~整形~文脈$と`行内~整形~文脈$との相互作用 ］について，より良い定義を追加した。 `1553$issue ◎ Added better definition of interaction between block formatting contexts and inline formatting contexts in block containers that establish inline formatting contexts. (Issue 1553)
• 要素とその~boxの間で~prop値が反映される仕方をより明瞭に定義した（要素が複数の~boxを生成する事例において）。 `1643$issue ◎ More clearly defined the way property values are reflected between an element and its boxes (in the case of an element generating multiple boxes). (Issue 1643)
• 空~text~objは、~CSS具現化~用には無視されることを明確化した。 `1808$issue ◎ Clarified that empty text objects are ignored for CSS rendering. (Issue 1808)
• `display$p による文書~意味論に対する効果は無いことを明確化した — これは~UAに共通的な~bugなので。 `2355$issue ◎ Clarified that display has no effect on document semantics, since this is a common bug in UAs. (Issue 2355)
• `display$p の`算出値$の定義における誤りを修正した（様々な~propにより誘発される`塊~化$, `行内~化$の規則に因り，それは “`as specified^en” 【指定されたとおり／指定値】 とは言えないので）。 `1716$issue ◎ Fixed error in definition of display’s computed value (which is definitely not “as specified”, due to blockification and inlinification rules triggered by various properties). (Issue 1716)
• `文書~順序$の定義を追加した。 ◎ Added definition for document order.
• 付録 B の `display:contents$p に対する詳細に無かった~SVG要素を追加した `2118$issue 。 ~SVG属性による効果を明確化した `2502$issue 。 ~MathML用の挙動も追加した `2167$issue 。 ◎ Added missing SVG elements to Appendix B’s details on display: contents (Issue 2118), clarified effect of SVG attributes (Issue 2502), and defined behavior for MathML (Issue 2167).
• 将来~仕様の策定者~向けに，匿名~box構築~規則について いくつかの指針を追加した。 `1643$issue ◎ Added some guidance to future spec authors of anonymous box construction rules. (Issue 1643)
• “整形~文脈になる” についての節を、それが利用されている CSS Containment に戻した。 【この用語は、その仕様からも除去された。】 ◎ Pushed the section about “becoming a formatting context” back to CSS Containment where it is used.
• 様々な細かい言い回しの修正点と明確化。 ◎ Various minor wording fixes and clarifications.

2017 年 1 月 26 日付 作業草案 からの変更点は： ◎ Changes since the 26 January 2017 Working Draft include:

• `inline-list-item^v 値は除去した — `inline list-item^v に等価なので。 ◎ Remove inline-list-item value that is equivalent to inline list-item.
• `display:contents$p の文脈における挙動を定義するため、`要素~木$に`~text~node$の概念0を追加するとともに，`~box木$に`~text連なり$の概念0を追加した。 `19$issWD, `32$issWD ◎ Added the notion of “text nodes” to the element tree, and “text runs” to the box tree to define behavior in the context of display: contents. (Issue 19, Issue 32)
• 根~要素は “~flow内にある” ものと定義した。 `3$issWD ◎ Defined that the root element is “in flow”. (Issue 3)
• `first-line$pe, `first-letter$pe と `run-in$v との相互作用を定義した。 `5$issWD, `42$issWD ◎ Defined interaction of ::first-line/::first-letter and run-in. (Issue 5, Issue 42)
• ［ 塊／行内／同行見出し ］は、`~flow~layout$における挙動のみを規定することを明確化した。 それは、他の文脈では無視される。 ◎ Clarified that block/inline/run-in only dictates behavior in flow layout; it is ignored in other contexts.
• 同行見出しは行内~boxの一種である — 行内~boxの “様なもの” ではなく。 ◎ Run-ins are a type of inline box, not just "like" an inline box.
• 同行見出しによる~box木の繰り替えが再帰性を欠いていたのを修正した。 `45$issWD ◎ Fixed the lack of recursion in of run-in’s box-tree munging. (Issue 45)
• `display:contents$p が “非通例的~要素” にどう働くかを述べる付録を追加した。 `8$issWD, `18$issWD ◎ Added an appendix on how display: contents works on “unusual elements”. (Issue 8, Issue 18)
• `塊~化$と`行内~化$の規則を — 特に~layout内部の表示型の取扱いについて — 修正した `35$issWD, `57$issWD ◎ Fix blockification and inlinification rules, particularly handling of layout-internal types. (Issue 35, Issue 57)
• ~box木における種々の修復の相互作用を明確化した。 `38$issWD, `48$issWD ◎ Clarified interaction of various box tree fixups. (Issue 38, Issue 48)
• 整形~文脈になることの定義を追加した。 ◎ Added the definition of becoming a formatting context.
• その他の細かい修正点や明確化。 ◎ Miscellaneous minor fixes and minor clarifications.

~commentの集積 もある。 ◎ A Disposition of Comments is also available.

2015 年 10 月 15 日付 作業草案 からの変更点は： ◎ Changes since the 15 October 2015 Working Draft include:

• `box-suppress^p （または `display-or-not^p ） ~propは、利用事例に関する論をもっと深めるため，この仕様の次の~levelまで先送りされた。 ◎ Deferred the box-suppress/display-or-not property to the next level of Display, in order to provide time for futher discussion of use cases.
• 非通例的~要素 — 置換~要素, ~form-controlなど — の内容に対する `display:contents$p による効果を指定した。 ◎ Specified the effects of display: contents on unusual elements such as replaced elements and form controls.
• `display:contents$p に因り，要素の~boxが生成されないとしても、依然として，要素に対する `before$pe `after$pe 疑似要素による自前の~boxは存在することを明確化した。 ◎ Clarified that an element’s ::before and ::after pseudo-elements still exist if its own box is not generated due to display: contents.
• `display:contents$p にされようが、~event伝播は影響されないことを明確化した。 ◎ Clarified that event bubbling is not affected by display: contents.
• ［ 同行見出し, ~flow外の要素, `first-letter$pe ］の間の相互作用を明確化した。 ◎ Clarified interaction of run-ins with out-of-flow elements and ::first-letter.
• ［ `table-caption$v ／ `table-cell$v ］の`内縁~表示型$には `flow-root$v を利用するように切り替えた — それらは常に、整形~文脈の根を形成するので。 ◎ Switched table-caption and table-cell to use flow-root as their inner display type, since they always form a formatting context root.
• 残りの課題は閉鎖して，~risk下~listを追加した。 ◎ Closed off remaining issues and added at-risk list.

2015 年 7 月 21 日付 作業草案 からの変更点は： ◎ Changes since the 21 July 2015 Working Draft include:

• `~flow内$, `~flow外$ の定義を用語集に追加した。 ◎ Added definitions for in-flow and out-of-flow to glossary.

2014 年 9 月 11 日付 作業草案 からの変更点は： ◎ Changes since the 11 September 2014 Working Draft include:

• `display-inside^p, `display-outside^p, `display-extras^p 下位propを除去した — 単に `display^p が複合的な値をとるようにすることへの支持を受けて。 （これは、何を組み合せれるかについて，拘束を課すことにより行われた。 この仕様の将来~levelでは、不必要または求められなくなったなら，これらの制約は緩められるかもしれない。） ◎ Removed display-inside, display-outside, and display-extras longhands, in favor of just making display multi-value. (This was done to impose constraints on what can be combined. Future levels of this specification may relax some or all of those restrictions if they become unnecessary or unwanted.)
• ［ ~flow~layout`表示型$をより良く表し, 要素を明示的に `~BFC$ 根に切り替えられるようにする ］ための`内縁~表示型$として、 `flow$v, `flow-root$v が創出された。 （これは、この目的を達成することを意図する `after$pe { `clear^p: `both^v; } や `overflow$p: `hidden^v の様な~hackの必要を無くすはずである。） ◎ Created the flow and flow-root inner display types to better express flow layout display types and to create an explicit switch for making an element a BFC root. (This should eliminate the need for hacks like ::after { clear: both; } and overflow: hidden that are intended to accomplish this purpose.)

~privacyと保安~上の考慮点

この仕様が導入する~privacyや保安~上の新たな考慮点はない。 ◎ This specification introduces no new privacy or security considerations.