在Chrome和Firefox中的高度呈现方式不同 [英] Heights rendering differently in Chrome and Firefox

问题描述

我发现如果我们设置了 height：auto 或 height：0〜100％用显式值设置父级的高度，并且其块级子级具有底部边距，那么它将在Chrome中计算高度不同，但在Firefox中不会。对于设置 height：1％的情况：

http://codepen.io/anon/pen/BjgKMR

  html {background：pink;} body {background：yellow;} div {height：1％;} inner {margin-bottom：30px; margin-top：20px;}  

 < div& < p class =inner>块级元素< / p>< / div>  

$ b

div 块的高度将计算为 margin-bottom + p元素的内容高度。我对为什么 height：1％应该计算为 auto ，因为父元素 html 和 body 标签）未明确设置其高度，但具有不同的高度，因为我们直接将高度设置为 auto ？

如果我们直接设置为 height：auto ，它将清楚地设置高度作为其子块级元素的高度，不包括其底部边距。

  html {background：pink;} body {background：yellow;} div {height：auto;} inner {margin-bottom：30px; margin-top：20px;}  

 < div> ; p class =inner>块级元素< / p>< / div>  

我已经阅读CSS 2.1规范，并认为我的问题可能覆盖了height属性和margin collapse主题，但仍然不能理解为什么它的行为不同在Chrome ver。 47.0.2526，虽然Firefox ver。 44.0.2将显示相同值的高度。

已列出的参考资料：

https://www.w3.org/TR/CSS2/visudet.html#the-height-property

• 10.5：percentage

  
  

  ...如果未指定包含块的高度显式地（即，它取决于内容高度），并且此元素不是绝对定位，该值计算为自动。 ...

  
  




• 10.6.3正常流程中的块级非替换元素溢出计算为可见。

  
  

  ...如果'height'是'auto'，高度取决于元素是否有任何块级子节点以及是否有填充或边框：

  
  
  

  元素的高度是从其顶部内容边缘到第一个适用的距离：

  
  
  1. 最后一行的底边框，如果框建立了一个或多个行的内联格式上下文
  
  
  2. 其最后一个流入子元素的底部（可能已折叠）边缘的底部边缘，如果子元素的底部边距不会与元素的下边距折叠
  
  
  3. 最后一个流入儿童的下边框边缘，其上边距不会与元素的下边距折叠
  
  
  4. 零，否则
  为零。
  

  
  

< a href =https://www.w3.org/TR/2011/REC-CSS2-20110607/box.html#collapsing-margins =nofollow> https://www.w3.org/TR/ 2011 / REC-CSS2-20110607 / box.html＃collapsing-margins

• 8.3.1合拢边距。

  
  

  如果元素没有，流入块元素的顶部边缘将与其第一个流入块级子元素的顶部边距合拢顶部边框，没有顶部填充，并且孩子没有间隙。

  
  
  

  高度为自动且最小高度为零的流入块框的下边距与其最后一个流入折叠块级子级的底部边距，如果框没有底部填充和没有底部边框，并且子级的底部边距不会与具有间隙的顶部边距折叠。

  
  
  

  ...如果框的顶部和底部边距相邻，则边距可以通过它折叠。在这种情况下，元素的位置取决于其与其边缘被折叠的其他元素的关系。

  
  
  

  
  
  • 如果元素的边距与其父上边距折叠，则框的顶边框边缘被定义为与父元素
  
  
  • 否则，元素的父元素不会参与边距折叠，或只涉及父元素的底边距。
  
  

  
  

元素的上边框边缘的位置与元素具有非零底边框时的位置相同。 >

解决方案

首先，你有W3C标准，这是一套浏览器制造商的指南。 p>

然后你有浏览器制造商，他们可以自由地做任何他们想要的（通过Internet Explorer的偏差历史证明）。

特别是，对于CSS的百分比高度，浏览器之间的行为有明显的区别。

您已发布了一个示例。这是另一个：

Flexbox中的百分比高度：Chrome / Safari与Firefox / IE

Chrome和Safari根据父级的 height 属性的值来解析flex项目的百分比高度。

看来Webkit浏览器遵循规范的更传统的解释：

CSS height 属性

百分比百分比高度。相对于生成的框的包含块的高度计算百分比。如果未明确指定包含块的高度，并且此元素未绝对定位，则该值计算为自动。

自动
高度取决于其他属性的值。

换句话说，对于在流内工作的百分比高度

这是规范的传统解释：术语height表示的值， height 属性。我自己的看法是，这种语言是模糊的，可以解释，但 height 属性要求已成为主要的实现。在处理百分比值时，我从未见过 min-height 或 max-height p>

但是，最近，Firefox和IE已经拓宽了他们的解释，接受flex高度。

使用父级Flex高度作为子级百分比高度参考的Firefox和IE示例：

• Chrome在列布局中忽略弹性基础


• Webkit无法填充弹性父类的100％高度


• Chrome在Chrome中的flexbox项目中的高度不正确


• Chromebox中的Flexbox- - 如何限制嵌套元素的大小？

知道哪些浏览器符合规范是有点困难的， ，正如我前面提到的，规范语言似乎模糊和开放解释。

定义的这部分最后一次更新是在1998年（ CSS2 ），以及新形式的高度（如弹性高度）的出现，似乎已经过期了。

我认为公平地说，当涉及百分比高度，直到规范定义得到更新，你可以期望在浏览器之间呈现差异。

< hr>

替代解决方案

这里有两个替代方案，当想要一个子元素取父母的全高。 p>

1. 将 display：flex 应用于父级。这会自动设置 align-items：stretch ，它会告诉孩子展开父级的完整可用高度。




2. 在父级和上应用 position：relative position：absolute;高度：100％; width：100％。使用绝对定位时，父元素的高度百分比将不会超过指定的高度。

I found if we set a block level element with height:auto or height: 0~100% without set up parent's height with explicitly value, and its block level child has bottom margin, then it will calculate height differently in Chrome, but not in Firefox. For the case which set height: 1%:

http://codepen.io/anon/pen/BjgKMR

html {
  background: pink;
}

body {
  background: yellow;
}

div {
  height: 1%;
}

inner {
  margin-bottom: 30px;
  margin-top: 20px;
}

<div>
  <p class="inner">block level element</p>
</div>

The height of div block will be calculated as the margin-bottom + content height of p element. I am confused about why the height: 1% should be computed as to auto because the parent elements(html and body tag) not set its height explicitly, but has different height as we just directly set the height to auto?

If we directly set it to height: auto, it will clearly just set the height as its child block-level element's height, which is not include its bottom margin.

html {
  background: pink;
}

body {
  background: yellow;
}

div {
  height: auto;
}

inner {
  margin-bottom: 30px;
  margin-top: 20px;
}

<div><p class="inner">block level element</p></div>

I have read the CSS 2.1 spec and think about my question might covered with the height property and margin collapse topic, but still cannot understand why it behaves different in Chrome ver. 47.0.2526, though Firefox ver. 44.0.2 will display the height with same value.

Listed references:
https://www.w3.org/TR/CSS2/visudet.html#the-height-property

• 10.5: percentage

  ... If the height of the containing block is not specified explicitly (i.e., it depends on content height), and this element is not absolutely positioned, the value computes to 'auto'. ...

• 10.6.3: Block-level non-replaced elements in normal flow when overflow computes to visible.

  ... if 'height' is 'auto', the height depends on whether the element has any block-level children and whether it has padding or borders:

  The element's height is the distance from its top content edge to the first applicable of the following:

  1. the bottom edge of the last line box, if the box establishes a inline formatting context with one or more lines
  2. the bottom edge of the bottom (possibly collapsed) margin of its last in-flow child, if the child's bottom margin does not collapse with the element's bottom margin
  3. the bottom border edge of the last in-flow child whose top margin doesn't collapse with the element's bottom margin
  4. zero, otherwise

https://www.w3.org/TR/2011/REC-CSS2-20110607/box.html#collapsing-margins

• 8.3.1 collapsing margins.

  The top margin of an in-flow block element collapses with its first in-flow block-level child's top margin if the element has no top border, no top padding, and the child has no clearance.

  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.

  ... If the top and bottom margins of a box are adjoining, then it is possible for margins to collapse through it. In this case, the position of the element depends on its relationship with the other elements whose margins are being collapsed.

  • If the element's margins are collapsed with its parent's top margin, the top border edge of the box is defined to be the same as the parent's.
  • Otherwise, either the element's parent is not taking part in the margin collapsing, or only the parent's bottom margin is involved. The position of the element's top border edge is the same as it would have been if the element had a non-zero bottom border.

解决方案

So first you have the W3C standards, which are a set of guidelines for browser makers.

And then you have the browser makers, who are free to do whatever they want (as evidenced by a history of deviations by Internet Explorer).

In particular, with CSS percentage heights, there are clear differences in behavior among browsers.

You've posted one example. Here's another:

Percentage Heights in Flexbox: Chrome/Safari vs Firefox/IE

When working with flexbox, Chrome and Safari resolve percentage heights on flex items based on the value of the parent's height property. Firefox and IE11/Edge prioritize the parent's flex height.

It appears Webkit browsers adhere to a more traditional interpretation of the spec:

CSS height property

percentage
Specifies a percentage height. The percentage is calculated with respect to the height of the generated box's containing block. If the height of the containing block is not specified explicitly and this element is not absolutely positioned, the value computes to "auto".

auto
The height depends on the values of other properties.

In other words, for percentage height to work on an in-flow child, the parent must have a set height.

That is the traditional interpretation of the spec: The term "height" means the value of the height property. My own view is that this language is vague and open to interpretation, but the height property requirement has become the predominant implementation. I've never seen min-height or max-height work on a parent when dealing with percentage values.

Recently, however, Firefox and IE have broadened their interpretation to accept flex heights, as well.

Examples of Firefox and IE using a parent's flex height as reference for a child's percentage height:

• Chrome ignoring flex-basis in column layout
• Webkit not filling 100% height of a flex parent
• Height is not correct in flexbox items in Chrome
• Flexbox in Chrome--How to limit size of nested elements?

Knowing which browsers are in compliance with the spec is a bit difficult because, as I mentioned before, the spec language seems vague and open to interpretation.

With the last update to this part of the definition being in 1998 (CSS2), and the advent of new forms of height such as flex height, an update seems long overdue.

I think it's fair to say that when it comes to percentage heights, until the spec definition gets an update, you can expect rendering differences among browsers.

---

Alternative Solutions

Here are two alternatives to consider when wanting a child element to take the parent's full height.

1. Apply display: flex to the parent. This automatically sets align-items: stretch, which tells the child to expand the full available height of the parent.

2. Apply position: relative on the parent and position: absolute; height: 100%; width: 100% on the child. With absolute positioning, a percentage height will work without a specified height on the parent.

这篇关于在Chrome和Firefox中的高度呈现方式不同的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！