您知道单值语法：.thing { display: block; }。“block” 是一个单值。 display 有很多单值。例如，inline-flex，它类似于 flex，因为它成为一个弹性容器，但表现得像一个内联级元素而不是块级元素。这有点直观，但一个可以更广泛地应用相同概念并同样直观的双值系统会更好。
要深入了解，您应该阅读 Rachel Andrew 的博文 CSS Display 属性的双值语法。规范 也是一篇不错的读物，Miriam 的这段视频也是如此
在我的脑海中，它是这样映射的
block 或 inline，然后选择 flow、flow-root、flex、grid 或 table。如果它是 list-item，则为第三个值。您基本上从每一列中选择一个来描述您想要的布局。因此，我们一直使用的现有值大致映射如下
考虑上面这两列的另一种方式是 **“外部”和“内部”** display 值。外部，就像它如何与周围的其他元素一起流动。内部，就像布局如何在这些元素内部发生。
您真的可以使用它吗？
其实不能。Firefox 70 是第一个支持它的浏览器，而且据我所知，Chrome 或 Safari 方面没有其他支持信号。它是 CSS 的一次重大改进，但在日常使用中，还需要几年时间。像布局这样重要的东西，您不希望仅仅为了这个稍微有点描述性的好处而让它失败。它可能也不值得使用 @supports 等进行渐进增强。
花絮
- 查看 自动转换 部分。仅仅因为您将元素设置为特定的 display，并不意味着它可能不会被某些情况覆盖。我假设它主要是在谈论元素被强制成为弹性项目或网格项目。
- 存在隐式简写。例如，如果您使用
inline list-item，则实际上是inline flow list-item，而list-item是block flow list-item。看起来都相当直观。 - 您仍然可以使用诸如
table-row和table-header-group之类的内容。这些都是单值处理，就像contents和none一样。 - 第一列从技术上讲也包括
run-in，但据我所知，没有浏览器曾经支持过run-indisplay。 - 第二列从技术上讲包括
ruby，但我从未理解过它到底是什么。
我们如何谈论 CSS
我喜欢 Rachel 如何将此更改与更合理的思维和教学模型联系起来
… 它们以框是块级还是内联级以及子元素的行为来正确解释框与其他框的交互。我认为，为了理解什么是 display 以及它的作用，它们提供了非常有用的澄清。因此，我开始使用这两个值来教授 display，以帮助解释更改格式上下文时发生了什么。
看到新功能得到实施总是令人兴奋的，我希望其他浏览器也能尽快实施这些双值版本。然后，在不远的将来，我们将能够像现在解释它一样编写 CSS，清楚地展示框与其子元素行为之间的关系。
嗨，Chris，
啊哈，感谢您提供的新视角。引用的 Rachel Andrew 博文中 CodePen 的内容也非常清楚！
补充
“#奇怪之处 (…) 据我所知，没有浏览器曾经支持过 run-in display。”
您还记得您 2010 年的文章 css-tricks.com/run-in 吗？ ;-)
文章中写道：“Firefox 完全不支持它，包括版本 4 测试版。WebKit 系列（Safari 和 Chrome）支持它，Opera 和 IE8 也支持它。”
同时
– Firefox 赢了！
– Internet Explorer 仍然支持它，直到生命周期结束（IE11），在您的测试页面 css-tricks.com/examples/Runin 中，所有鱼在 IE11 中都“游动”；但 MS-Edge 已放弃支持。
– Chrome、Opera 和 Safari 也放弃了支持；现在只有 Opera Mini 支持它。
– 全球只有 1.65% 的浏览器用户可以享受 run-in（0.19% IE8/IE10、1.85% IE11、1.3% Opera Mini）。
– 请参阅：caniuse.com/#search=run-in。
– w3c css-valisator 对您的测试页面给予 绿色，符合规范。
– 但 FF 和 Chrome 中的开发者面板毫不犹豫地将 run-in 视为“无效属性值”。
结论：实际上，我们可以将 display: run-in; 视为无效。
抱歉，是什么让您得出这个结论？规范（第 2.1 节之前的说明性表格）和 Rachel Andrew 的文章似乎都清楚地列出了这种组合是完全有效的，这意味着“块级块容器，即块框”，等效于旧的
block值。换句话说，它是一个简单的块框，不建立新的块级格式上下文，因此它不会清除任何浮动，并允许其子元素的边距与其自身的边距折叠），这与block flow-root（即flow-root）形成对比，后者创建一个建立新 BFC 的块框。哎呀！我可以澄清一下。我指的是 规范中的这部分
我认为这意味着，即使您希望某些东西表现得像块容器，如果它是弹性子元素（或类似的东西，我认为），它也会以这种方式表现。
啊，是的，“块化”和“内联化”这些东西确实很棘手（尤其是后者）。基本上，是的，当我们尝试将某些东西放置到无法按其值建议的方式表现的环境中时，就会发生这种情况。“块化”最初的内联元素更为常见（传统的例子是浮动和绝对定位的内联元素，将内联元素转换为弹性或网格项目，是的，具有相同的效果）。“内联化”对我来说仍然是异乎寻常的事情（我还没有在实践中见过它，并且查看规范时只在 Ruby 上下文中发现了它，而 Ruby 本身是 相当异乎寻常的东西）。但基本上，据我理解，这意味着当我们必须将块容器放置到仅接受内联子元素的环境中时，CSS 必须将此块转换为内联块（
inline flow-root），因为inline flow（即inline）将丢失任何块容器功能。确实如此，但它是一个不同的东西，它只是 独立格式上下文，而不是自动框类型转换。它确实会影响行为，但不会更改任何
display值组件。因此，请修复图表上的红线:)
令人印象深刻！感谢分享这篇文章。