repaint(重绘)是在一个元素的外观被改变，但没有改变布局的情况下发生，如改变visibility、outline、前景色。
"According to
Opera , repaint is expensive because the browser must verify the visibility of all other nodes in the DOM tree."
当repaint发生时，浏览器会验证DOM树上的所有其它结点的visibility属性。
reflow(回流)是导致DOM脚本执行低效的关键因素之一。页面上任何一个结点触发reflow，都会导致它的子结点及祖先结点重新渲染。Nicole举了个例子：
<body>
<div class=”error”>
<h4>My Module</h4>
<p><strong>Error:</strong>Description of the error…</p>
<h5>Corrective action required:</h5>
<ol>
<li>Step one</li>
<li>Step two</li>
</ol>
</div>
</body>
当p结点上发生reflow，div.error和body也会重新渲染，甚至h5和ol也会受到影响。
Nicole总结了在哪些情况下会导致reflow发生：
- 改变窗囗大小
- 改变文字大小
- 添加/删除样式表
- 内容的改变，如用户在输入框中敲字(这样也会-_-||)
- 激活伪类，如:hover (IE里是一个兄弟结点的伪类被激活)
- 操作class属性
- 脚本操作DOM
- 计算offsetWidth和offsetHeight
- 设置style属性
reflow是不可避免的，只能将reflow对性能的影响减到最小。Nicole提出6点建议：
- Change classes on the element you wish to style (as low in the dom tree as possible)
尽可能限制reflow的影响范围。以上面的代码为例，要改变p的样式，class不要加在div上，通过父级元素影响子元素不好。最好直接加在p上。
- Avoid setting multiple inline styles
通过设置style属性改变结点样式的话，每设置一次都会导致一次reflow。所以最好通过设置class的方式。
- Apply animations to elements that are position fixed or absolute
实现元素的动画，它的position属性应当设为fixed或absolute，这样不会影响其它元素的布局。
- Trade smoothness for speed
权衡速度的平滑。比如实现一个动画，以1个像素为单位移动这样最平滑，但reflow就会过于频繁，CPU很快就会被完全占用。如果以3个像素为单位移动就会好很多。
- Avoid tables for layout
不要用tables布局的另一个原因就是tables中某个元素一旦触发reflow就会导致table里所有的其它元素reflow。在适合用 table的场合，可以设置table-layout为auto或fixed，这样可以让table一行一行的渲染，这种做法也是为了限制reflow的 影响范围。
- Avoid JavaScript expressions in the CSS (IE only)
很多情况下都会触发reflow，如果css里有expression，每次都会重新计算一遍。
从渲染过程上来讲，mozilla有过CSS的书写建议：
- 1.显示样式
- display/position/float/clear
- 2.自身样式
- width/height/margin/padding/border/background
- 3.内容样式
- line-height/text-align/font系列（font-size/font-weight）/color/text-decoration/vitical-align
