css表达式不会造成页面重新渲染。
HTML的渲染原理:
Web页面运行在各种各样的浏览器当中，浏览器载入、渲染页面的速度直接影响着用户体验简单地说，页面渲染就是浏览器将html代码根据CSS定义的规则显示在浏览器窗口中的这个过程。先来大致了解一下浏览器都是怎么干活的：
1.
用户输入网址（假设是个html页面，并且是第一次访问），浏览器向服务器发出请求，服务器返回html文件；
2.
浏览器开始载入html代码，发现<head>标签内有一个<link>标签引用外部CSS文件；
3.
浏览器又发出CSS文件的请求，服务器返回这个CSS文件；
4.
浏览器继续载入html中<body>部分的代码，并且CSS文件已经拿到手了，可以开始渲染页面了；
5.
浏览器在代码中发现一个<img>标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码；
6.
服务器返回图片文件，由于图片占用了一定面积，影响了后面段落的排布，因此浏览器需要回过头来重新渲染这部分代码；
7.
浏览器发现了一个包含一行Javascript代码的<script>标签，赶快运行它；
8.
Javascript脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个<div>
（style.display=”none”）。杯具啊，突然就少了这么一个元素，浏览器不得不重新渲染这部分代码；
css的渲染原理；
1、浏览器下载的顺序是从上到下，渲染的顺序也是从上到下，下载和渲染是同时进行的。
2、在渲染到页面的某一部分时，其上面的所有部分都已经下载完成（并不是说所有相关联的元素都已经下载完）。
3、如果遇到语义解释性的标签嵌入文件（JS脚本，CSS样式），那么此时IE的下载过程会启用单独连接进行下载。
4、并且在下载后进行解析，解析过程中，停止页面所有往下元素的下载。
5、样式表在下载完成后，将和以前下载的所有样式表一起进行解析，解析完成后，将对此前所有元素（含以前已经渲染的）重新进行渲染。
6、JS、CSS中如有重定义，后定义函数将覆盖前定义函数。
写css最逃不开的应该是浏览器兼容问题了吧，因为css存在一些 未定义行为 ，各个浏览器都会按照自己的渲染规则来表现，就会存在表现不一致的情况，还有很多属性某些浏览器不支持，很多时候需要我们用更通用的方法来实现一些UI效果。本文重点来说说浏览器是如何把一个页面渲染出来的。
主要流程：
DOM生成、样式计算、布局、分层、图层绘制、栅格化、合成显示
下面主要讲css相关的几个步骤
我们书写的html最终都会被解析成一颗dom树，它来表达的dom结构能被浏览器所理解，那css做的就是赋予dom节点每个元素样式。当然，我们写的css也是不能直接被浏览器理解的，需要转化成styleSheets，我们在浏览器控制台输入document.styleSheets就能看到。
styleSheets要应用到各个元素上还需要两个步骤：
最后得出dom节点每个元素的具体样式。
得到dom树后，浏览器会遍历这棵树，把所有可见的节点加到布局树中，再进行布局计算，得到每个节点的坐标位置，保存在布局树中。
得到每个元素的具体位置后，还不能开始绘制页面，因为我们的页面并不是二维的，3D变换，z轴排序、页面滚动等效果都需要图层来实现。所以浏览器会为特定的节点生成专门的图层便于这些效果的实现。那什么样的节点会创建专门的图层呢，包括拥有层叠上下文属性的元素以及需要剪裁(clip)的地方，可以看一下 css（五）层叠
在浏览器开发者工具会有一个Layers标签，这里面可以直观地看到页面的分层情况
当改变了元素宽高或者几何位置的时候，就会触发 重排 ，需要走一遍完整的渲染过程，开销最大。
如果只是改变颜色，那么布局阶段就不需要执行，可以直接进入绘制阶段，所以叫 重绘 ，省去了布局和分层，效率会比重排要高一些。
而使用css的transform实现动画效果，则可以避开重绘和重排，只进行后续的合成操作，被称为 合成 ，能大大提升绘制效率。
Ps 合成操作实在非主线程(GPU进程)上执行的，不占用主线程资源
这是应该是浏览器开发者应该关心的(页面加载更快，用户就会更愉快)。Mozilla有一篇文章： about best practices . Google 当然也很关心这个问题，他们也有这样一篇文章：Optimize browser rendering。让我们了解下他们主要倡导的东东，然后讨论他们的实用性。从右到左浏览器如何读取你的CSS选择器有一个很重要的原则，那就是它们从右到左读取。这意味这像 ul li a[title="home"] 这样的选择器，a[title="home"] 将是最先被读取的。这一部分通常被称为 “key selector” （可否称为“目标选择器” -_-!）选择器的最后一部分，也是被选择的标签。ID's 是最有效率的，通用符是最慢的有四种目标选择器：ID, class, tag和通用符。看下他们各自的效率如何:#main-navigation { } /* ID (最快) */
body.home #page-wrap { } /* ID */
.main-navigation { } /* Class */
ul li a.current { } /* Class *
ul { } /* Tag */
ul li a { } /* Tag */
* { } /* Universal (最慢) */
#content [title='home'] /* Universal */ 然后我们结合从右到左和目标选择器的概念，我们可以知道下面这个选择器并不高效：
#main-nav li { } /* 看着很快实则很慢 */
尽管这让人有点费解......因为ID's是最高效的，浏览器可以通过ID迅速的找到 li。但事实是，li 标签是被先读取的。不要用标签修饰死也不要像下面这样干：ul#main-navigation { }ID's 是唯一的，所以不需要用标签修饰，这只会让它更低效。
如果你可以避免的话，也不要用它修饰 class 。class 不是唯一的，所以理论上你可以把它用在不同的标签。如果你愿意的话，你可以用标签控制不同的样式，这样你可能需要标签修饰（比如：li.first），但这样做的人很少，所以，don't .绝对没有比用后代选择器更糟糕的做法了David Hyatt:
后代选择器是CSS里最昂贵的选择器，昂贵得可怕——特别是当它放在标签和通用符后面时。
就如下面这个东东一样，绝对的效率毒瘤：html body ul li a { }一个选择器渲染失败比这个选择器被渲染更高效我不是很确定是否有更好的证据去证明这一点，因为如果你有大量的选择器在CSS样式表里无法找到，这样的事情貌似很离奇，但一点必需注意的是，从右到左的解释一个选择器来说，一旦它找不到，那它就会停止尝试。然而如果它找到了，那它就需要花更多精力去解释了。试想一下为何你这样写选择器思考下这东东：#main-navigation li a { font-family: Georgia, Serif}你可能不需要从 a 选择器开始（如果你只是想换个字体）。下面这个可能更高效些：#main-navigation { font-family: Georgia, Serif}实用性还刻前面提到的Mozilla的一篇文章？已经有十年了。事实是：计算机比十年前变慢了（不是我理解错了，还是作者想说现在的WEB越来越复杂了）。我感觉这东东在当年似乎还更受重视。十年前我还是个21岁的英俊小生，当然我不觉得那里我会认识css这东东。所以我也无法跟你讲以前的情况......但我觉得渲染效率的问题之所以没被重视是因为这从来就不是一个大问题。
这是我的一些看法：不管怎样上面提到的东东都是有意义的，你可以按照上面的方法去做，因为它并不会限制你的CSS制作。但你也没必要太教条主义。如果你是个完美主义者，而之前又没有考虑过那东东，那是时候去重新看一下你之前写的一些样式是否有改进的地方了。如果你没发现你的网站明显的渲染缓慢，那大可别太在意，在以后的工作中多注意就行了。超级快速，零实用性我们知道ID's 是最高效的选择器。当你想让渲染速度最高效时，你可能会给每个独立的标签配置一个ID，然后用这些ID写样式。那会超级快，也超级荒唐。这样的结果是语义极差，维护难到了极点。即使在核心部分你也不应该见过这样做的。我认为这个可以提醒我们不要为了高效的CSS放弃语义和可维护性。Thanks to Jason Beaudoin for emailing me about the idea. If anyone knows more about this stuff, or if you have additional tips that you use in this same vein, let’s hear it!顺便提一下，因为CSS选择器被很多javascript库使用，上面提到的东东仍然适用，ID选择器还是最快的，后代选择器和类似的东东比较慢。PS：看谁还敢用N多的后代选择器。。。还有反对我用ID的。。。哇哈哈。。。经典论坛交流：
