一、Chrome虽好，可别贪杯哦~

一般我们对Chrome浏览器的评价是：Chrome好棒！Chrome好潮！Chrome就是多来A梦，要什么有什么！

但是，再好的奶茶也会有过期的时候。很多次遇到，Chrome下的渲染表现是最糟糕的那个。比方说，在transform内部做CSS3 animation动画，Chrome会让文字一会儿粗一会儿细，甚至上下跳动，于是我们可以100%确认，这个页面是公的，会CSS3 animation的挑逗有反应。

嘛，毕竟只是细节上的不爽，睁一只眼闭一只眼也就过去了。但是，有些影响布局的bug可就没法视而不见了。你可能会惊讶：“纳尼！Chrome这么好的浏览器有bug, 会不会是你看错了？”

虽说Chrome是你见过的最单纯的姑娘，但是，真正相处久了，终究会发现，如果真的足够纯，就不叫奶茶了。

我这里给大家展示两个Chrome absolute绝对定位引发的渲染bug, 这些bug已经历经很多代（写本文时候使用Chrome版本是40）都没有修复了，跟我来~

二、Chrome下absolute绝对定位元素部分display属性值不渲染bug

此bug描述如下：

Chrome浏览器下，绝对定位元素，其display值在inline/inline-block和block之间切换时候，是不重新渲染的。

百闻不如一见，您可以狠狠地点击这里：Chrome浏览器下绝对定位元素display渲染bug demo

我们进入demo，首先引入眼帘的是这个样子（张小姐抹白是为了节约至少60%图片尺寸大小，下同）：

此时，图片没有任何display设置，是默认的inline-block水平。要知道，元素absolute绝对定位，如果没有left/top等值，位置是不移动的(可参考我很多年前写的“CSS 相对/绝对(relative/absolute)定位系列（二）”一文)，因此，紧随文字显示是没有任何问题的。

但是，当我们点击左边这个按钮，修改图片的display水平为block，尼玛图片居然还傻不拉几呆在后面，而且就Chrome浏览器是这样，IE8+以及Firefox之流^①都是萌萌哒换行显示：

//zxx: IE7也不会换行，但那是解析bug；而这里Chrome是不渲染bug~

如何修复此bug？
2年前的这个时候，我曾写过一篇文章：“利用重绘解决IE下JS交互产生的定位重叠等棘手bug”，可谓前端从业必读基础技能文章。
用一句话概述为就是：“遇到一些交互渲染bug时候，不妨触发浏览器的重绘，说不定问题即解决。”

这里Chrome不渲染bug修复中心思想也是一样的，就是触发重绘。但是，术业有专攻，代码有小受。上文中抛出来的visibility:inherit/visible切换方法在Chrome这里是没有效果滴！“我了个擦，这是要闹哪样？” 稍安勿躁，上帝关上了一扇门，那我们就换一个门出去。

这里隆重推出新时代webkit/blink内核渲染bug修复神器，业界俗称webkit届haslayout的东西：-webkit-transform: translateZ(0);

肉眼看上去，此申明对页面元素不会有什么影响；但是，好比老IE时代的zoom: 1。灭虫能力堪比敌敌畏！

我们回到demo，注意右侧蓝色按钮，对，就是那个含有“同时toggle translateZ”字样的按钮，此按钮是干嘛的呢？就是触发左侧按钮点击同时，给图片父级toggle切换translateZ(0)属性值，如下截图：

结果，图片正常渲染咯！——换行，跟随，换行，跟随，…… 好棒！

三、Chrome下absolute绝对定位元素具有overflow属性的块状子元素visibility hover不渲染bug

此bug具体描述如下：

Chrome浏览器下，绝对定位元素，同时visibility:hidden时候，如果子元素具有块状水平，同时设置了overflow:hidden; 则父元素hover时候，无法让子元素visibility:visible渲染生效！

百闻不如一见，您可以狠狠地点击这里：Chrome浏览器下绝对定位元素visibility渲染bug demo

我们先看HTML代码：

<div class="hover">     Chrome罕见visibility渲染bug(<em>hover me</em>)     <div class="abs_vh">         <div id="bug" class="bug"><img src="mm1.jpg"></div>     </div> </div>

然后CSS代码：

.abs_vh {     position: absolute; visibility: hidden; } .bug {     overflow: hidden; /* 重要条件 */ } .hover:hover .bug {     visibility: visible; /* Chrome浏览器下，此声明无效 */ }

可以看到，HTML结构超级简单，CSS更是简单，总共就出现了4个CSS声明，但是，就是且必须这4个声明同时存在的时候，bug才会出现。

回到demo，我们hover demo页面文字，结果Chrome浏览器下，没有任何反应：

而爱意之流，火狐之流却风生水起：

由于一般人不会用到visibility的recover重置特性（类似还有cursor）（差不多3年前“您可能不知道的CSS元素隐藏‘失效’以其妙用”一文有介绍过visibility这个特性），因此，此bug几乎很难重现。

如何修复此bug？
我就不卖关子了，修复此bug的关键就是上面吹嘘过的神器，被誉为webkit界中的haslayout：-webkit-transform: translateZ(0);. 在需要visibility显示的元素添加这段CSS申明就可以了。

我们回到demo，有个光杆按钮，干嘛用的呢？给.bug这个元素toggle -webkit-transform: translateZ(0)这个声明。例如，我们点击下这个按钮，然后再去hover文字：

哦！！！小妹子图片显示出来了！好棒！

demo本着演示目的，在JS内联，实际上，要修复，CSS足矣，如下：
然后CSS代码：

.abs_vh {     position: absolute; visibility: hidden; } .bug {     overflow: hidden; } .hover:hover .bug {     visibility: visible;      -webkit-transform: translateZ(0); /* 没错，靠的就是你！*/ }

由于上面两个bug都是来自Chrome，所以，神器使用了私有前缀，既不会影响其他OK浏览器，也似乎在大声表明：我就是hack，我就是补丁！

四、酒不醉人人自醉，结语写完就去睡

Chrome渲染的些bug自然不止本文这两个，主要是本文bug都由绝对定位absolute引发（可能高效渲染计算设计导致），然后都可以-webkit-transform: translateZ(0)修复，因此就放在一起讲了。

记得以前似乎见到过浮动随机渲染的bug；去年做iOS原型时候遇到过过场渲染的bug（夜太深，具体我记不清了），也是使用translateZ修复的。所以，如果大伙儿在折腾webkit内核页面时候，遇到奇怪渲染问题，都可以试试webkit界的haslayout, 渲染问题修复神器-webkit-transform: translateZ(0)，说不定会有好运降临！

技术不止，进步不断，说不定下个版本问题就会被修复，到时，还希望广大同学提个醒，我好及时更新。

感谢阅读，有任何问题都欢迎交流！

（本篇完）