这是一篇关于边距合并的一句话博客文章:当两个块级元素堆叠在一起时,它们之间的垂直空间是上面元素的 margin-bottom
和下面元素的 margin-top
中较大的那个。
这有点奇怪,并且让人感到困惑。正如您所料,它们有几个注意事项。
我发现当人们对它有所领悟时,它会成为完美的微型博客文章。MDN 甚至认为 有一个专门的页面。
虽然边距合并行为乍一看有点不直观,但在多个嵌套元素的情况下,它确实让生活更轻松,在这种情况下,这种行为通常是理想的。
这可能不是 CSS 中最直观的方面,但这里需要记住的是,它背后有一些逻辑,一旦您学会了它,神秘感和困惑就会突然消失!
您是否看到边距合并如何使事情变得棘手?我个人在处理排版时会经常遇到这种情况,这很令人沮丧。
边距合并可能令人沮丧,但了解它何时以及如何发生将使您更容易在出现问题时解决它们。
如果不明确了解边距合并何时发生,可折叠边距可能会让人头疼。处理或避免它们的步骤是 [要] 确切了解我们正在处理的哪种可折叠边距情况。
边距合并是每本 CSS 书籍的第一章或第二章都会提到的内容。很久以前,当我了解样式表时,我当然读过它。
边距合并的概念是理解 CSS 中盒模型的基础,但实际上它相当复杂,并且可能令人困惑。描述边距合并工作方式的规范非常详细,但难以理解。
我并不是说这是一个被过度博客化的主题(没有什么),但它是一个有趣的线索。当这么多人觉得有必要解释最终如此小的事情时,就会发生一些奇怪的事情(可能是坏事)。
毫无疑问,这就是为什么它被认为是 CSS 设计中的错误之一
框的顶部和底部边距永远不应该被允许自动合并在一起,因为这是 所有边距合并邪恶的根源。
强调 他们的,并且实际上是整个列表中唯一的粗体文本。
如果您想阻止这种行为,您需要做一些可能比其价值更具副作用的事情,比如浮动元素。它并不像启动一个新的 块级格式化上下文 那样简单,因为这是 display: flow-root;
所做的,并且 不起作用。
您可能最好还是了解它并通过 系统地在一个方向上流动边距 或 变得奇怪 来处理它出现的任何情况。
我不对与其他元素共享空间的元素应用边距。我将元素放在一个父 div 中,子元素的边距只是改变了父元素的大小。由于这种习惯,我不必处理边距合并。
边距合并也可能发生在父元素和子元素之间。
在 HTML 和 CSS 的早期,边距合并非常有用。想象一下,有两个具有默认顶部/底部边距的段落。如果没有边距合并,它们之间的空间将加倍。
一旦我们开始使用 CSS 进行布局,它就变得有问题的。我发现从我的重置样式表中的每个元素中简单地删除顶部边距非常有用。然后您不必担心垂直边距相互接触。
当我第一次学习 css 时,嗯,是在 2005 年吗?没有人告诉我边距合并(而且没有太多优秀的书籍或在线资源),所以我对为什么它们没有加起来感到困惑。当我了解到它是一些用来使段落和标题间距方便的事情时,我嗤之以鼻。然后我尝试浮动一些东西,比如向左,并在右侧加上 20px 的边距… 好吧,IE6 很乐意将它加倍(为什么?当然是因为它做到了!)我很快学会了喜欢填充,并且可能 8 年都没有再考虑过边距。
我仅仅因为它们具有负值才开始喜欢它们!
一旦我牢牢掌握了边距合并,我就意识到它在进行某些布局方面的价值。例如,如果您有一篇文章,边距合并在对文章主体元素(如段落、图像嵌入、标题等)设置边距方面非常方便。如果没有边距合并,我将不得不诉诸同级选择器,但有了它,我可以为文章文本的多种配置使用更简单的 CSS。
边距描述了其他元素应该远离当前框的最小空间,边距共享空间并合并是有道理的。如果有的话,我认为子元素的边距应该合并到父元素的填充中,因为填充基本上是向内的边距。
我认为边距是“至少这么多空间”定义的空白空间。因此,当您有两个边距相遇时,它们必须就它们之间应该有多少空白空间达成一致。
边距 1:“嗯,我需要至少 25px 的空间在我下方。”
边距 2:“切,我需要至少 50px 的空间在我上方!”
边距 1:“哦,好吧,那超过了 25px,所以我们就会用那个了。”
边距 1 和 2 在 50px 处握手,每个人都开开心心地走了。
它实际上不是边距合并,因为没有人失去他们需要的任何空白空间。它是边距协议。他们都同意只使用满足他们双方需求的尽可能多的空间。
你知道什么让我生气吗?在 flex 元素内部,边距不会合并。我不知道为什么,但我觉得这有点背叛了我的预期。