这是一个比较罕见的bug，而且跟高度100%没有关系，跟absolute定位也关系不太大。

详细的bug复现DEMO请见我的这篇文章：《【bug记录】IE8，包含块min-height/height共存时的高度计算错误》

问题复现

• A元素是B元素的包含块。
• A元素设置overflow:hidden;，并同时设置了height和min-height，同时height计算值 < min-height
• 原生IE8浏览器，或者IE9浏览器的IE8兼容性模式（以下统称为IE8）

期待结果：

• 若B元素为absolute定位元素，A元素为relative定位元素，则B元素的包含块高度为A元素的padding-edge高度
• 若A、B元素均为常规流定位元素，则B元素的包含块高度为A元素的content-box高度
• 若A元素同时设置了min-height和height，同时height计算值小于min-height。因为height权重小于min-height，最终A元素的content-box高度计算值应以min-height为准

IE8的bug是：

• 若B元素的包含块的content-box的值计算错误，在height计算值小于min-height的同时，误取了heihgt值作为其包含块的content-box部分
• B元素跟其包含块有关的属性，如百分比top/bottom/百分比height均受到影响，因此，B元素的位置可能受到影响
• A元素的最终高度计算依然正确
• 受到影响的仅仅是以A元素为包含块的元素，包括B元素

问题发生流程试解释

以LZ的DEMO为例子：

// 以下为正常的CSS计算值得出流程，自顶向下

// 视口
// ┗html
// 意味着: 视口是html的包含块

视口 // height=600px
┗html // height:100% -> height=600px
　┗body // height:100% -> height=600px
　　┕.wrapper // height:100% & min-height:720px; -> height=720px
　　　┗.u-pagebg // height:100% -> height=720px

IE8中出现了什么样的差错呢，从现象尝试着解释一下bug的成因：

// 以下为IE8中的CSS计算值得出流程

视口 // height=600px
┗html // height:100% -> height=600px
　┗body // height:100% -> height=600px
　　┕.wrapper // height:100% -> height≈600px
　　　┗.u-pagebg // height:100% -> height=600px
　　　　          // 在计算完.u-pagebg的包含块的高度之后
　　　　          // .wrapper才受到min-height约束，如下
　　┕.wrapper // height:100% & min-height:720px; -> height=720px

解决方案

• 去掉.wrapper上的overflow:hidden;
• 若需要overflow:hidden;，加在不【同时设置了height、min-height，且height计算值<min-height】的地方。（为了防止断句错误，用了【】来区分分句)

老实说，LZ这样的布局上为何需要overflow:hidden;，我看不出来太大意义。720px是一个非常高的值，比大部分用户的屏幕都要高。

况且这样的布局也用不着绝对定位，负margin定位也能做到。

overflow & absolute定位 是低版本IE里面布局bug的万恶之源之二，如果有兼容性要求，LZ使用之前请三思。

最后，IE10，IE11的IE8兼容性模式，都是扯淡。微软的IE想跟过去断离关系，又不肯断干净，偷偷把bug修复了，搞了个这么不伦不类的兼容性模式，在兼容性上毫无帮助。