Chrome和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">block level element</p></div>
div
块的高度将计算为margin-bottom + content height of p element
。我很困惑为什么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">block level element</p></div>
我已经阅读了CSS 2.1规范,并考虑我的问题可能包含高度属性和边缘折叠主题,但仍然无法理解为什么它在Chrome ver中表现不同。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',则高度取决于元素是否具有任何块级子元素以及它是否具有填充或边框:
元素的高度是从其顶部内容边缘到下面第一个适用的距离:
如果框使用一行或多行建立内联格式化上下文,则为最后一个行框的下边缘
如果孩子的下边距没有因元素的下边距而崩溃,则其最后一个流入子项的底部(可能是折叠)边缘的下边缘
最后一个流入子项的下边界边缘,其上边距不会随元素的下边距折叠
零,否则
https://www.w3.org/TR/2011/REC-CSS2-20110607/box.html#collapsing-margins
8.3.1折叠边距。
如果元素没有顶部边框,没有顶部填充,并且子节点没有间隙,则插入块元素的上边距将与其第一个流入块级子节点的上边距折叠。
如果盒子没有底部填充,则“高度”为“auto”且“min-height”为零的流入块盒的底部边缘将与其最后一个流入块级子的底部边缘折叠底部边框和孩子的下边距不会因具有间隙的上边距而崩溃。
...如果框的顶部和底部边距相邻,则边距可能会通过它折叠。在这种情况下,元素的位置取决于其与边缘正在折叠的其他元素的关系。
如果元素的边距与其父元素的上边距折叠,则框的上边框边缘定义为与父元素相同。
否则,元素的父元素不参与边距折叠,或仅涉及父元素的下边距。元素顶部边框边缘的位置与元素具有非零底边框时的位置相同。
郎朗坤