CSS 显示模块 Level 3

1. 引言

本节是规范性的。

CSS 采用一个源文档，该文档被组织为 由 树构成， 其中包含 元素 （可以包含其他 元素和文本节点的混合） 以及 文本节点 （可以包含文本）， 并将其渲染到一个画布上， 例如你的屏幕、一张纸，或一个音频流。 虽然任何这样的源文档都可以用 CSS 渲染， 但最常用的类型是 DOM。[DOM] （这些更复杂的树类型中的某些类型可能具有其他类型的节点， 例如 DOM 中的注释节点。 就 CSS 而言， 所有这些额外类型的节点都会被忽略， 就好像它们不存在一样。）

为此，它会生成一种中间结构， 即 盒树， 它表示已渲染文档的格式化结构。 盒树中的每一个 盒 都表示其对应的元素（或 伪元素） 在画布上的空间和/或时间中的表现， 而 盒树中的每一个 文本序列 同样表示其文本节点的相应内容。

为了创建盒树， CSS 首先使用层叠和继承， 为源树中每个元素和文本节点上的每个 CSS 属性 指派一个计算值。 （参见 [CSS-CASCADE-3]。）

然后，对于每个元素， CSS 会根据该元素的 display 属性的规定， 生成零个或多个盒。 通常，一个元素会生成一个单独的 盒， 即主体盒， 它表示该元素自身，并在盒树中包含其内容。 然而，某些 display 值 （例如 display: list-item） 会生成多个盒 （例如一个主体块盒和一个子 标记盒）。 而某些值 （例如 none 或 contents） 会导致该 元素和/或其后代根本不生成任何 盒。 盒通常按其 display 类型来称呼——例如，由具有 display: block 的元素生成的 盒称为“块盒”或简称为“块”。

盒会被指派与生成它的 元素相同的样式，除非另有说明。 一般而言，继承属性会被指派给主体盒， 然后通过盒树继承到 同一元素生成的任何其他盒。 非继承属性默认应用到 主体盒， 但当元素生成多个盒时， 有时会被定义为应用到不同的盒： 例如，应用到 table 元素的 border 属性 会应用到它的表格网格盒， 而不是它的 主体表格 包装盒。 如果值计算过程改变了这些盒的样式， 并且请求了元素的样式 （例如通过 getComputedStyle()）， 则该元素会针对每个属性 反映该属性所应用到的盒上的值。

类似地，每一段连续的兄弟文本节点序列都会生成一个文本序列， 其中包含它们的文本内容， 并被指派与生成它的 文本节点相同的样式。 但是，如果该序列不包含任何文本，它就不会生成 文本 序列。

在构造盒树时， 由某个元素生成的盒是 任何祖先元素的主体盒的后代。 在一般情况下， 一个元素的主体盒的直接 父盒 是其最近的、生成盒的祖先元素的 主体盒； 然而，也存在一些例外， 例如 run-in 盒、 会生成多个容器盒的显示类型（如表格）， 以及介入的匿名盒。

匿名盒是一个不与任何元素关联的盒。 匿名盒会在某些情况下生成， 用于在盒树需要 特定的嵌套结构、 而这种结构并未由元素树生成的盒提供时 对其进行修补。 例如，一个表格单元格盒 需要一种特定类型的父盒（表格行盒）， 如果其父盒不是表格行盒， 它就会在自身周围生成一个 匿名表格行盒。 （参见 [CSS2] § 17.2.1。） 与元素生成的盒不同，后者的样式严格通过元素树继承； 匿名盒（仅存在于 盒树中） 会通过其 盒树父级关系进行继承。

在布局过程中， 盒和文本序列可以被分成多个 片段。 例如，当一个行内 盒和/或 文本序列 跨行断开， 或者当一个块盒跨 页面或分栏断开时， 就会发生这种情况，这一过程称为分片。 这也可能因文本的双向重排而发生 （参见 应用双向重排 算法， 见 CSS 书写模式） 或因更高层级的显示类型盒 拆分而发生， 例如 块内行内拆分 （参见 CSS2§9.2） 或 块内跨列元素拆分 （参见 CSS 多列布局）。 因此，一个 盒由一个或多个盒片段组成， 而一个 文本序列由一个或多个 文本片段组成。 关于分片的更多信息，参见 [CSS-BREAK-3]。

注：许多 CSS 规范是在这些 术语被厘清之前编写的， 或者会错误地引用这些事物， 因此在旧规范使用这些术语时应谨慎看待。 应当可以从上下文中推断出它们真正指的是什么术语。 当你发现规范中的错误时，请报告错误， 以便修正。

注：关于“aural”盒树 及其与 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 属性定义元素的显示类型， 它由元素如何生成盒的两个基本性质组成：

• 内部显示类型， 它定义（如果它是非替换元素）其生成的格式化上下文的种类， 决定其后代盒如何布局。 （替换元素的内部显示不在 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

该元素生成一个ruby 容器盒 并建立一个ruby 格式化上下文， 同时还会将其基准级内容 整合进其父级格式化上下文 （如果它是行内的） 或生成一个适当外部显示类型的包装盒 （如果它不是）。[CSS-RUBY-1]

如果指定了 <display-inside> 值但省略了 <display-outside>， 则元素的外部 显示类型默认为 block——但 ruby 除外，它默认为 inline。

2.3. 生成标记盒：list-item 关键字

list-item 关键字 使元素生成一个 ::marker 伪元素 [CSS-PSEUDO-4]， 其内容由该元素的 list-style 属性指定 （CSS 2.1§12.5 列表）[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

该元素是一个内部 ruby 元素。 它生成适当的内部 ruby 盒， 该盒参与ruby 格式化上下文。[CSS-RUBY-1]

ruby-base 和 ruby-text 具有 flow 内部显示类型。

具有布局专用显示类型的盒，在被放置到不兼容的父级中时， 会在自身周围生成匿名包装盒， 如其各自规范所定义。

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

块盒
└匿名表格盒
 └匿名表格行组盒
  └匿名表格行盒
   └表格单元格盒

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

表格盒
└匿名表格行组盒
 └表格行盒
  └表格单元格盒

2.5. 盒生成：none 和 contents 关键字

虽然 display 可以控制元素将生成的盒的类型， 它也可以控制元素是否会生成任何盒。

<display-box> 关键字定义如下：

contents

元素自身不生成任何盒， 但其子级和伪元素仍会照常生成盒和文本序列。 为了盒生成和布局的目的， 该元素必须被视为在元素树中 已经被其内容替代 （包括其源文档子级和伪元素， 例如 ::before 和 ::after 伪元素， 它们会照常在元素子级之前/之后生成）。

注：由于只有盒树受到影响， 任何基于文档树的语义， 例如选择器匹配、事件处理 和属性继承， 都不会受到影响。 然而截至撰写时， 主流浏览器并未正确实现这一点， 因此在 Web 上使用此特性时必须谨慎， 因为它可能阻止可访问性工具 访问元素的语义。

此值在替换元素 以及其渲染不完全由 CSS 控制的其他元素上会计算为 display: none； 详见附录 B：display: contents 对特殊元素的影响。

注：替换元素和表单控件会被 特殊处理， 因为只移除元素自身生成的盒 基本上是一种未定义的操作。 随着用例 （以及更精确的渲染模型）发展，此行为可能会被完善， 因此为保持向前兼容，作者应在此类元素上使用 display: none， 而不是 display: contents。

none

元素及其后代 不生成任何盒或文本序列。

类似地，如果文本节点被 定义为按 display: none 行为处理， 它也不生成任何文本序列。

具有这两个值之一的元素没有内部或外部显示类型， 因为它们根本不生成任何盒。

注：由于这些值会使受影响的元素 不生成盒， 匿名盒生成规则会完全忽略这些被省略的元素， 就好像它们不存在于盒树中一样。

然而，基于标记的关系不会受这些值影响， 因为它们只是渲染时效果。 例如， 虽然它们可能影响哪个表格单元格看起来位于某一列中， 但它们不会影响哪个表格单元格与某个特定的列元素相关联。 类似地，它们不能影响哪个 HTML summary 元素与某个特定表格相关联， 或者一个 legend 是否被认为是在标注某个特定 fieldset 的内容。

2.6. 预组合的行内级显示值

CSS level 2 对 display 使用单关键字语法， 要求同一布局模式的块级和行内级变体使用不同的关键字。 这些 <display-legacy> 关键字映射如下：

inline-block

计算为 inline flow-root。

inline-table

计算为 inline table。

inline-flex

计算为 inline flex。

inline-grid

计算为 inline grid。

注：尽管这些关键字及其等价形式 会计算为相同的值， 它们的指定值仍保持不同。

注：getComputedStyle() 序列化规则 将始终输出这些预组合关键字， 而不是等价的双关键字对， 这是由于最短、最向后兼容的序列化原则。

2.7. 自动盒类型转换

某些布局效果要求盒类型进行 块化 或 行内化， 这会将盒的计算外部显示类型 分别设置为 block 或 inline。 （这对完全不生成盒的显示 类型没有影响， 例如 none 或 contents。） 此外：

• 如果一个块盒（block flow）被行内化， 其内部 显示类型会被设置为 flow-root， 以便它仍保持为块容器。

• 如果一个行内盒（inline flow）被行内化， 它会递归地行内化其所有流内子级， 以便没有块级后代 打断它所参与的行内格式化上下文。

• 出于遗留原因， 如果一个行内块盒 （inline flow-root） 被块化， 它会变成一个 block 盒 （失去其 flow-root 性质）。 为保持一致， 一个 run-in flow-root 盒 也会被块化 为一个 block 盒。

• 如果一个布局内部盒被块化， 其内部 显示类型会转换为 flow， 以便它成为一个块容器。 行内化对 布局内部盒没有影响。 （不过，放置到这种行内上下文中 通常会导致它们被包裹在 一个类型适当的匿名行内级盒中。）

注：当盒与其上下文不匹配时， 有两种方法用于修补盒类型。 一种是转换 display 的计算 值，例如这里描述的块化和行内化。 另一种发生在盒树构造期间（在计算值已确定之后）， 即创建中介匿名盒， 例如在表格、 ruby 和流布局中发生的情况。

2.8. 根元素的主体盒

根元素的显示类型 始终被块化， 并且其主体盒始终 建立一个独立格式化上下文。 此盒的包含 块是初始包含块。

此外，根元素上的 display 为 contents 时，会计算为 block。

3. 显示顺序：order 属性

盒通常会按照它们在源文档中出现的相同顺序 显示和布局。 在某些格式化 上下文中， order 属性可用于重新排列盒的顺序， 以有意造成元素逻辑顺序 与其在二维视觉画布上的空间排列 之间的差异。 （参见 § 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>

计算机入门套装

这是钱能买到的最好的计算机， 如果你没有很多钱的话。

• 计算机
• 显示器
• 键盘
• 鼠标

弹性和网格容器 会按照order 修改后的文档顺序 来布局其内容， 从编号最低的序数分组开始并向上排列。 具有相同序数分组的项按它们在源文档中出现的顺序布局。 这也会影响绘制顺序 [CSS2]， 效果完全等同于这些弹性/网格项在源文档中被重新排序。 弹性/网格容器的绝对定位子级 在确定其相对于弹性/网格项的绘制顺序时， 会被视为具有 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] 以及弹性布局中的折叠的弹性项 [CSS-FLEXBOX-1]。 但在所有其他情况下， （即除非另有规定） 这只是使该盒不可见， 就像 hidden 一样。

注：目前，许多用户代理和/或可访问性 工具 未能正确实现可见元素与不可见元素存在语义关系时 对可访问性的影响， 因此，例如， 使具有特殊角色的父元素（如表格行）不可见， 同时让具有特殊角色的子元素（如表格单元格）保持可见， 对这些工具的用户而言可能会产生问题。 作者应避免创建这些情况， 直到工具环境得到改善。

不可见盒不会被渲染 （就像完全透明一样）， 不能交互 （并表现得如同具有 pointer-events: none）， 会从导航中移除 （类似于 display: none）， 并且也不会被渲染到语音 （除非 speak 为 always [CSS-SPEECH-1]）。 然而，与 display: contents 一样， 它们作为容器的语义角色不受影响， 以确保任何 visible 后代 都能被正确解释。

注：如果 speak 为 always， 则一个原本不可见的盒 会被渲染到语音， 并且可以使用非视觉/空间方法与之交互。

<p>电影前面的象征含义在结尾变得显而易见，
  当揭示出 <spoiler-text><span>Luke 是自己的父亲</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 盒的行为与任何其他行内级盒完全相同， 但有以下例外：

• 具有 flow 内部显示 类型的 run-in 盒会行内化其 内容。
• 如果一个run-in 序列 紧接在一个块盒之前， 且该块盒不建立新的块格式化上下文， 则该序列会被插入为该块盒的直接子级： 在其 ::marker 伪元素的盒（如果有）之后， 但位于该块内容生成的任何其他盒之前 （包括 ::before 伪元素生成的盒，如果有）。 如果可能，这种重新设定父级关系会递归进行 （使 run-in 实际上成为其格式化上下文中 最深的后续“段落”的一部分， 并在此过程中收集新近相邻的 run-in）。

  随后，重新设定父级的内容会像原本就在该处作为子级一样格式化。 注意，受影响的只有布局，而不是继承， 因为非匿名盒的属性继承仅基于元素树。

• 否则 （如果该run-in 序列没有跟随这样的块）， 会在该 run-in 序列 以及所有紧随其后的行内级内容周围生成一个匿名块盒 （直到下一个 run-in 序列为止，但不包括它，如果存在的话）。

run-in 序列是连续同级run-in 盒 以及介于其间的空白和/或流外盒组成的最大序列。

注：此陈述意味着如果流外盒位于两个 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]

主体盒

当一个元素生成一个或多个盒时， 其中一个是主体 盒， 它包含其后代盒和生成内容， 并且也是参与任何定位方案的盒。

某些元素除了主体盒之外还可能生成额外的盒 （例如 list-item 元素， 它会生成一个额外的标记盒， 或者 table 元素， 它会生成一个主体表格包装盒 和一个额外的表格网格盒）。 这些额外的盒相对于主体盒进行放置。

行内级

参与行内布局的内容。 具体而言，行内级盒和文本序列。

块级

参与块布局的内容。 具体而言，是块级盒。

行内盒

一个行内级的非替换 盒，其内部 显示类型为 flow。 行内盒的内容参与与该行内盒自身相同的行内格式化上下文。

inline

在没有歧义时，用作行内 盒或行内级盒的简写， 或作为形容词表示行内级。 后一种用法已废弃。

原子行内

一个行内级盒，它是替换的（例如图像）， 或建立新的格式化上下文（例如 inline-block 或 inline-table）， 并且不能跨行拆分 （不像行内盒和ruby 容器那样）。

任何内部显示类型不是 flow 的行内级盒都会建立一个指定内部 显示类型的新格式化上下文。

块容器

块容器要么只包含 参与行内格式化上下文的行内级盒， 要么只包含 参与块格式化上下文的块级盒 （可能会生成匿名块盒以确保此约束， 如 CSS2§9.2.1.1 中定义）。

只包含行内级内容的块容器 会建立一个新的行内格式化上下文。 该元素随后还会生成一个根 行内盒， 该盒包裹其所有行内内容。 注意，这个根行内盒概念 实际上取代了 CSS2§9.2.2.1 中引入的“匿名行内元素”概念。

如果块容器的父格式化上下文不是块格式化上下文， 它会建立一个新的块格式化上下文； 否则，当其自身参与块格式化 上下文时， 它要么为其内容建立一个新的块格式化 上下文， 要么继续它所参与的那个上下文， 这由其他属性的约束决定 （例如 overflow 或 align-content）。

注：一个块容器盒可以同时建立 块格式化上下文 和行内格式化上下文。

块盒

一个块级盒，同时也是一个块 容器。

注：并非所有块容器盒都是块级盒： 非替换行内 块和非替换表格单元格， 例如，都是块容器 但不是块级盒。 类似地，并非所有块级盒都是块容器： 块级替换元素（display: block） 和弹性容器（display: flex），例如， 就不是块容器。

block

在没有歧义时，用作块盒、 块级盒或块容器盒的简写。

替换元素

内容处于 CSS 格式化模型范围之外的元素， 例如图像或嵌入文档。 例如，HTML img 元素的内容 通常由其 src 属性所指定的图像替代。

替换元素通常具有自然尺寸。 例如，位图图像具有以绝对单位指定的自然宽度和自然高度 （由此显然可以确定自然比例）。 另一方面，其他对象可能没有任何自然尺寸 （例如空白 HTML 文档）。 参见 [css-images-3]。

如果用户代理认为这些尺寸可能向第三方泄露敏感信息， 可以认为替换元素没有任何自然尺寸。 例如，如果某个 HTML 文档会根据用户的银行余额改变自然大小， 那么 UA 可能希望将该资源视为没有自然尺寸。

替换元素的内容不纳入 CSS 格式化模型； 但其自然尺寸会用于各种布局计算。 替换元素始终建立一个独立格式化上下文。

非替换元素 是未被替换的元素， 即其渲染由 CSS 模型决定的元素。

包含块

一个矩形，它构成与其关联的盒 进行尺寸确定和定位的基础。 特别地，包含 块不是盒 （它是一个矩形）， 不过它通常派生自某个盒的尺寸。 每个盒都会相对于其包含块获得一个位置， 但它并不被此包含块限制； 它可以溢出。 短语“一个盒的包含块”是指 “该盒所在的包含块”， 而不是它所生成的包含块。

一般而言，一个盒的边缘 会作为后代盒的包含块； 我们说一个盒为其后代“建立” 该包含块。 如果引用了某个包含块的属性， 则它们引用的是生成该包含块的盒上的值。 （对于初始包含块， 除非另有规定，值取自根元素。）

详见 [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]。 此外，某些类型的格式化上下文会交错并共存： 例如，行内格式化上下文存在于 建立它的元素的块格式化上下文之中， 并与之交互； 而 ruby 容器会在其ruby 基准容器参与的行内格式化上下文 之上叠加一个ruby 格式化上下文。

一个盒要么建立新的独立格式化上下文， 要么延续其包含块的格式化上下文。 在某些情况下， 它还可能另外建立新的（非独立）共存格式化上下文。 然而，除非另有规定， 建立新的格式化上下文 会创建一个独立格式化上下文。 盒所建立的格式化上下文类型 由其内部显示类型决定。 例如，网格容器建立新的网格格式化上下文， ruby 容器建立新的ruby 格式化上下文， 而块 容器可以建立新的块格式化上下文 和/或新的行内格式化上下文。 参见 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 元素

一个 svg 元素，如果具有 CSS 盒布局 （这包括其父级为 HTML 元素的所有 svg， 以及文档根元素）

display: contents 计算为 display: none。

所有其他 SVG 容器元素，它们同时也是 可渲染元素

SVG 文本内容子元素

use

display: contents 会将该元素从格式化树中剥离， 并将其内容提升到原位置显示。 这些内容包括 use 的 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 虽然没有取得进展， 但为当前规范奠定了基础； 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] 中所定义， 并澄清了它指的是小视口尺寸。 （议题 6453）

自 2020 候选推荐以来的变更

自 2020 年 5 月 19 日候选推荐 以来的意见处理情况可供查看。

自 2020 年 5 月 19 日候选推荐 以来的变更 包括：

• 将“text run”重命名为“文本序列”。 （议题 7768）
• 定义了根元素， 并在 § 2.8 根元素的主体盒以及初始 包含块的定义中， 澄清了其作为块级内容的布局。 （PR 8095， 议题 7207， 议题 6480， 议题 7786）
• 从 [CSS-FLEXBOX-1] 引入了 order 属性定义， 因为它也适用于网格项。 （议题 5865）
• 从 [CSS2] 导入了 visibility 属性定义， 并将其更新得更加详尽和完整。 （议题 6123）
• 定义了带有布局内部 display 的替换 元素 会被视为 display: inline。 （议题 6000）
• 澄清了 <display-legacy> 值实际上会计算 为与其双关键字等价形式相同的值。 （议题 5575）

  inline-…

  行为如 计算为 inline …。

  注：尽管这些关键字及其等价形式会计算为相同的值， 它们的指定值仍保持不同。

  注：getComputedStyle() 序列化规则 将始终输出这些预组合关键字， 而不是等价的双关键字对， 这是由于最短、最 向后兼容的序列化原则。

• 澄清了块化和 行内化是计算值变更。 （议题 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”区分。
• 在 root → initial containing block 传播中添加了“unless otherwise specified”， 因为 HTML body 元素存在一些令人遗憾的特殊例外。

候选推荐状态之前的变更

意见处理情况可供查看。

自 2018 年 4 月 20 日工作草案以来的变更包括：

• 具有 display: contents 且行为如 display: none 的元素现在计算为 display: none。 （议题 2755）
• 区分了“新的”格式化上下文与独立 格式化上下文，因为某些格式化上下文会分层。 （议题 2597， 议题 1457）
• 定义了建立独立格式化上下文的块盒 具有 display 的已用值 flow-root， 以提供更方便的引用点。 （议题 1550）
• 澄清了 display 不可动画化（而不是离散动画化）。 （议题 2938）
• 小的编辑性修正。

自 2017 年 7 月 20 日工作草案以来的变更包括：

• 收紧了对 inline-block / inline flow-root 进行块化的规则， 以确保与 CSS2 兼容。 （议题 1246） 更新了对 run-in flow-root 的处理以匹配。 （议题 1715）

• 调整了 display 的语法， 将 list-item 关键字 列在最后。这会影响预期的序列化顺序。 （议题 1621）

• 更好地定义了在建立行内格式化上下文的块容器中， 块格式化 上下文与行内格式化上下文之间的交互。 （议题 1553）

• 更清楚地定义了属性值在元素及其盒之间反映的方式 （在元素生成多个盒的情况下）。 （议题 1643）

• 澄清了空文本对象在 CSS 渲染中会被忽略。 （议题 1808）

• 澄清了 display 对文档语义没有影响，因为这是 UA 中常见的错误。 （议题 2355）

• 修正了 display 的计算 值定义中的错误 （由于各种属性触发的块化和行内化规则，它绝对不是“按指定”）。 （议题 1716）

• 添加了文档顺序的定义。

• 向附录 B关于 display: contents 的细节中添加了缺失的 SVG 元素 （议题 2118）， 澄清了 SVG 属性的影响 （议题 2502）， 并定义了 MathML 的行为 （议题 2167）。

• 向未来规范作者添加了一些关于匿名盒构造规则的指导。 （议题 1643）

• 将关于“成为格式化上下文”的小节推回到使用该概念的 CSS Containment。

• 各种小的措辞修正和澄清。

自 2017 年 1 月 26 日工作草案以来的变更包括：

• 移除等价于 inline list-item 的 inline-list-item 值。

• 向元素树添加了“文本 节点”概念， 并向盒树 添加了“文本 片段”概念， 以定义 display: contents 上下文中的行为。 （议题 19， 议题 32）

• 定义了根元素是“流内”的。 （议题 3）

• 定义了 ::first-line/::first-letter 与 run-in 的交互。 （议题 5， 议题 42）

• 澄清了 block/inline/run-in 仅决定流布局中的行为；在其他上下文中会被忽略。

• Run-in 是一种行内盒，而不只是“像”行内盒。

• 修复了 run-in 盒树整理中缺少递归的问题。 （议题 45）

• 添加了一个附录，说明 display: contents 如何作用于“特殊元素”。 （议题 8， 议题 18）

• 修正块化和行内化规则， 特别是布局内部类型的处理。 （议题 35， 议题 57）

• 澄清了各种盒树修补之间的交互。 （议题 38， 议题 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 作为其内部显示 类型，因为它们始终形成一个格式化上下文根。
• 关闭了剩余议题并添加了有风险列表。

自 2015 年 7 月 21 日工作草案以来的变更包括：

• 向术语表添加了流内和流外的定义。

自 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. 本规范在用户代理的“隐身”模式上下文中应如何工作？

    没有不同。

15. 本规范是否将数据持久化到用户的本地设备？

    否。

16. 本规范是否有“安全考虑”和“隐私考虑”小节？

    是。

17. 本规范是否允许降低默认安全特征？

    否。