跨浏览器问题:极小的高度和崩溃的边缘

时间:2022-11-13 15:38:40

As you can see in this simple example:

正如你在这个简单的例子中看到的:

<div id="minheight">
    <p id="margin">Paragraph with a margin</p>
</div>
<div id="sibling">Sibling div</div>
#minheight {
    min-height: 100px;
    background: red;
}
#sibling {
    background: blue;
}

http://jsfiddle.net/peterbriers/B43th

http://jsfiddle.net/peterbriers/B43th

There is a difference between Chrome (35) and Firefox (29) in how it handles the collapsing margins on a block with a min-height that is larger than the child's margin.

Chrome(35)和Firefox(29)之间的区别在于,它如何处理一个小块的边缘,它的最小值大于孩子的边缘。

I tried to fully understand the specifications: http://www.w3.org/TR/CSS2/box.html#collapsing-margins , but I'm still unsure which browser handles this correctly. I would say Chrome is in the wrong, but Safari (7) does it the Chrome way too.

我试图完全理解这些规范:http://www.w3.org/TR/CSS2/box.html#折叠边距,但我仍然不确定哪个浏览器正确地处理了这些。我认为Chrome是错误的,但是Safari(7)也采用了Chrome的方式。

Which browser is correct, and how can I file a bug for the one that isn't doing it the right way? BTW: I'm not asking any fix by adding new block formatting context (adding overflow property)...

哪个浏览器是正确的,我如何为那些做得不正确的浏览器提交bug ?顺便说一句:我不会通过添加新的块格式化上下文(添加溢出属性)来要求任何修复……

1 个解决方案

#1


6  

OK, so this seems to be a very peculiar case.

这似乎是一个非常特殊的情况。

If you change min-height to height, the gap disappears in Chrome. Not only does Safari behave the same as Chrome, but so does IE. Firefox's behavior is unique to itself, and its behavior does not change when you make that adjustment to your CSS. This should come as a surprise, as you would not expect min-height and height to behave any differently in your given scenario.

如果你把最小的高度换成高度,这个差距就会在铬合金中消失。Safari不仅表现得和Chrome一样,IE也一样。Firefox的行为是自己独有的,当您对CSS进行调整时,它的行为不会改变。这应该是一个惊喜,因为您不会期望最小的高度和高度在您的给定场景中有任何不同的表现。

However, the spec has something interesting to say about min-height with respect to margin collapsing:

然而,该规范对于关于边距崩溃的问题有一些有趣的说法:

The following algorithm describes how the two properties influence the used value of the 'height' property:

下面的算法描述了这两个属性如何影响“高度”属性的使用值:

[...]

[…]

These steps do not affect the real computed values of the above properties. The change of used 'height' has no effect on margin collapsing except as specifically required by rules for 'min-height' or 'max-height' in "Collapsing margins" (8.3.1).

这些步骤不会影响上述属性的实际计算值。使用的“高度”的变化不会影响页边折叠,除非《页边折叠》中“最小高度”或“最大高度”的规定(8.3.1)特别要求。

Because you have not specified a fixed value for the height property on the same element that has a min-height, the computed value for height remains the default auto, even though the used value is floored to min-height.

因为您还没有为具有min-height的同一元素上的height属性指定一个固定值,所以计算出来的height值仍然是默认的自动值,即使使用的值被标记为min-height。

Therefore the following text from section 8.3.1 applies, and the margins between the block box and its child should collapse as a result, irrespective of min-height:

因此,第8.3.1节中所述的文本适用,并且该块盒与它的子块之间的边距将会因此而崩溃,而不考虑最小高度:

Two margins are adjoining if and only if:

当且仅当:

  • both belong to vertically-adjacent box edges, i.e. form one of the following pairs:

    它们都属于垂直相邻的盒形边,即形成以下对中的一对:

    • ...
    • bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height
    • 如果父节点有“自动”计算的高度,则最后一个流入子节点的底部边缘和其父节点的底部边缘

Note that it goes on to list some scenarios in which margins may or may not collapse:

请注意,它接着列出了一些利润率可能会或不会崩溃的情况:

Note the above rules imply that:

请注意上述规则暗示:

  • ...
  • The bottom margin of an in-flow block box with a 'height' of 'auto' and a 'min-height' of zero collapses with its last in-flow block-level child's bottom margin if the box has no bottom padding and no bottom border and the child's bottom margin does not collapse with a top margin that has clearance.
  • 子块的底部边距框的“高度”“汽车”和一个零的最小高度崩溃的子块级孩子的底部边距如果盒子没有底部填充和底部边界和孩子的底部边距不崩溃的顶边间隙。

... but it does not state what happens when the block box has height: auto and a non-zero min-height.

…但是它没有说明当块框具有高度:自动和非零最小高度时发生了什么。

Based on this, it would be safe to assume that the spec should be interpreted as I am doing. Therefore it looks like Firefox is not behaving quite correctly, and all other browsers are following the spec to the letter, despite what one might expect from the behavior of height and min-height.

基于此,可以安全地假设规范应该像我所做的那样进行解释。因此,看起来Firefox的行为不太正常,而且所有其他浏览器都严格按照规范行事,尽管人们可能会对其身高和最小身高的行为产生预期。

You can file a bug for Firefox here, although it looks like the developers have already made themselves aware of this issue.

您可以在这里为Firefox提交一个bug,尽管看起来开发人员已经意识到了这个问题。

#1


6  

OK, so this seems to be a very peculiar case.

这似乎是一个非常特殊的情况。

If you change min-height to height, the gap disappears in Chrome. Not only does Safari behave the same as Chrome, but so does IE. Firefox's behavior is unique to itself, and its behavior does not change when you make that adjustment to your CSS. This should come as a surprise, as you would not expect min-height and height to behave any differently in your given scenario.

如果你把最小的高度换成高度,这个差距就会在铬合金中消失。Safari不仅表现得和Chrome一样,IE也一样。Firefox的行为是自己独有的,当您对CSS进行调整时,它的行为不会改变。这应该是一个惊喜,因为您不会期望最小的高度和高度在您的给定场景中有任何不同的表现。

However, the spec has something interesting to say about min-height with respect to margin collapsing:

然而,该规范对于关于边距崩溃的问题有一些有趣的说法:

The following algorithm describes how the two properties influence the used value of the 'height' property:

下面的算法描述了这两个属性如何影响“高度”属性的使用值:

[...]

[…]

These steps do not affect the real computed values of the above properties. The change of used 'height' has no effect on margin collapsing except as specifically required by rules for 'min-height' or 'max-height' in "Collapsing margins" (8.3.1).

这些步骤不会影响上述属性的实际计算值。使用的“高度”的变化不会影响页边折叠,除非《页边折叠》中“最小高度”或“最大高度”的规定(8.3.1)特别要求。

Because you have not specified a fixed value for the height property on the same element that has a min-height, the computed value for height remains the default auto, even though the used value is floored to min-height.

因为您还没有为具有min-height的同一元素上的height属性指定一个固定值,所以计算出来的height值仍然是默认的自动值,即使使用的值被标记为min-height。

Therefore the following text from section 8.3.1 applies, and the margins between the block box and its child should collapse as a result, irrespective of min-height:

因此,第8.3.1节中所述的文本适用,并且该块盒与它的子块之间的边距将会因此而崩溃,而不考虑最小高度:

Two margins are adjoining if and only if:

当且仅当:

  • both belong to vertically-adjacent box edges, i.e. form one of the following pairs:

    它们都属于垂直相邻的盒形边,即形成以下对中的一对:

    • ...
    • bottom margin of a last in-flow child and bottom margin of its parent if the parent has 'auto' computed height
    • 如果父节点有“自动”计算的高度,则最后一个流入子节点的底部边缘和其父节点的底部边缘

Note that it goes on to list some scenarios in which margins may or may not collapse:

请注意,它接着列出了一些利润率可能会或不会崩溃的情况:

Note the above rules imply that:

请注意上述规则暗示:

  • ...
  • The bottom margin of an in-flow block box with a 'height' of 'auto' and a 'min-height' of zero collapses with its last in-flow block-level child's bottom margin if the box has no bottom padding and no bottom border and the child's bottom margin does not collapse with a top margin that has clearance.
  • 子块的底部边距框的“高度”“汽车”和一个零的最小高度崩溃的子块级孩子的底部边距如果盒子没有底部填充和底部边界和孩子的底部边距不崩溃的顶边间隙。

... but it does not state what happens when the block box has height: auto and a non-zero min-height.

…但是它没有说明当块框具有高度:自动和非零最小高度时发生了什么。

Based on this, it would be safe to assume that the spec should be interpreted as I am doing. Therefore it looks like Firefox is not behaving quite correctly, and all other browsers are following the spec to the letter, despite what one might expect from the behavior of height and min-height.

基于此,可以安全地假设规范应该像我所做的那样进行解释。因此,看起来Firefox的行为不太正常,而且所有其他浏览器都严格按照规范行事,尽管人们可能会对其身高和最小身高的行为产生预期。

You can file a bug for Firefox here, although it looks like the developers have already made themselves aware of this issue.

您可以在这里为Firefox提交一个bug,尽管看起来开发人员已经意识到了这个问题。