Chrome 和 Firefox 中的高度渲染方式不同 [英] Heights rendering differently in Chrome and Firefox

问题描述

我发现如果我们使用 height:auto 或 height: 0~100% 设置块级元素而没有使用明确的值设置父级的高度及其块级child 有底部边距，那么它会在 Chrome 中计算不同的高度，但在 Firefox 中不会.对于设置 height: 1%:

的情况

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

html {背景:粉红色；}身体 {背景:黄色；}div {高度:1%；}内{底边距:30px；边距顶部:20px；}

<p class="inner">块级元素</p>

div 块的高度将计算为margin-bottom + p 元素的内容高度.我很困惑 为什么 height: 1% 应该被计算为 auto 因为父元素(html 和 body 标签) 没有明确设置它的高度，但有不同的高度，因为我们只是直接将高度设置为 auto?

如果我们直接将其设置为height: auto，它显然只是将高度设置为其子块级元素的高度，不包括其底部边距.

html {背景:粉红色；}身体 {背景:黄色；}div {高度:自动；}内{底边距:30px；边距顶部:20px；}

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

我已阅读 CSS 2.1 规范并考虑我的问题可能涉及高度属性和边距折叠主题，但仍然无法理解为什么它在 Chrome 版本中表现不同.47.0.2526，虽然是 Firefox 版本.44.0.2 将显示相同值的高度.

列出的参考文献:
https://www.w3.org/TR/CSS2/visudet.html#the-height-property

• 10.5:百分比

  <块引用>

  ... 如果未明确指定包含块的高度(即，它取决于内容高度)，并且该元素不是绝对定位的，则该值计算为 'auto'....

• 10.6.3:当overflow 计算为visible 时，正常流中的块级非替换元素.

  <块引用>

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

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

  1. 最后一行框的底部边缘，如果框用一行或多行建立了内联格式上下文
  2. 最后一个流入子元素的底部(可能折叠)边距的底部边缘，如果子元素的底部边距不与元素的底部边距折叠
  3. 上边距不与元素的下边距折叠的最后一个流入子元素的下边框边
  4. 零，否则

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

• 8.3.1 折叠边距.

  <块引用>

  如果元素没有顶部边框、顶部填充并且子元素没有间隙，则流入块元素的顶部边距与其第一个流入块级子元素的顶部边距折叠在一起.

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

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

  • 如果元素的边距与其父元素的顶部边距折叠在一起，则框的顶部边框边缘被定义为与父元素的相同.
  • 否则，要么元素的父元素不参与边距折叠，要么只涉及父元素的底部边距.元素的顶部边框边缘的位置与元素具有非零底部边框时的位置相同.

解决方案

所以首先你要有 W3C 标准，这是一组针对浏览器制造商的指南.

然后是浏览器制造商，他们可以随心所欲地做任何想做的事(Internet Explorer 的偏差历史证明了这一点).

特别是，对于 CSS 百分比高度，浏览器之间的行为存在明显差异.

您发布了一个示例.这是另一个:

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

在使用 flexbox 时，Chrome 和 Safari 会根据父项的 height 属性值解析 flex 项目的百分比高度.Firefox 和 IE11/Edge 优先考虑父级的 flex 高度.

Webkit 浏览器似乎坚持对规范的更传统解释:

<块引用>

CSS height 属性

百分比
指定百分比高度.该百分比是根据生成的框的包含块的高度计算的.如果未明确指定包含块的高度并且该元素不是绝对定位，则该值计算为auto".

auto
高度取决于其他属性的值.

换句话说，为了让百分比高度适用于流入的孩子，父母必须有一个设定的高度.

这是规范的传统解释:术语高度"表示 height 属性的值.我自己的观点是，这种语言含糊不清，易于解释，但 height 属性要求已成为主要实现.我从未见过 min-height 或 max-height 在处理百分比值时对父级起作用.

然而，最近，Firefox 和 IE 已经扩大了他们的解释，以接受 flex 高度.

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

• Chrome 忽略列布局中的 flex-basis
• Chrome/Safari 未填充 Flex 父级的 100% 高度
• Chrome 中 flexbox 项目的高度不正确
• Chrome 中的 Flexbox--如何限制嵌套元素的大小?

了解哪些浏览器符合规范有点困难，因为正如我之前提到的，规范语言似乎含糊不清且易于解释.

这部分定义的最后一次更新是在 1998 年(CSS2)，以及诸如 flex height 等新高度形式的出现，更新似乎早就该更新了.

我认为可以公平地说，当谈到百分比高度时，在规范定义得到更新之前，您可以预期浏览器之间的渲染差异.

<小时>

替代解决方案

当希望子元素占据父元素的全高时，可以考虑以下两种选择.

1. 将 display: flex 应用到父级.这会自动设置 align-items:stretch，它告诉子级扩展父级的完整可用高度.

2. 在父对象上应用position:relative和position:absolute；高度:100%；宽度: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
• Chrome / Safari not filling 100% height of 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屋！