首先，CSS 的读取顺序是 从右向左
举个例子
它的读取顺序是：
那么，为什么读取顺序是从右向左呢？
举个例子：
假如 DOM 结构如上图，
假设匹配规则是 .mod-nav h3 span
如果从左向右匹配，过程是：
如果从右向左匹配：
总结：这是一个树形结构，很明显，从 child 开始找 parent 比从 parent 找 child 要高效
CSS 的后代选择器本身就是一种在标准里面不那么推荐的方式。首先，对浏览器来说，ID 选择器 #xx 是最快的，其次是 class 选择器、html 元素选择器等。
假如 DOM 的结构如上图，匹配规则是 .mod-nav h3 span。
若从左向右的匹配，过程是：从 .mod-nav 开始，遍历子节点 header 和子节点 div，然后各自向子节点遍历。在右侧 div 的分支中，最后遍历到叶子节点 a ，发现不符合规则，需要回溯到 ul 节点，再遍历下一个 li-a，假如有 1000 个 li，则这 1000 次的遍历与回溯会损失很多性能。
再看看从右至左的匹配：先找到所有的最右节点 span，对于每一个 span，向上寻找节点 h3，由 h3再向上寻找 class=mod-nav 的节点，最后找到根元素 html 则结束这个分支的遍历。
很明显，两种匹配规则的性能差别很大。之所以会差别很大，是因为从右向左的匹配在第一步就筛选掉了大量的不符合条件的最右节点（叶子节点）；而从左向右的匹配规则的性能都浪费在了失败的查找上面。
当然这是比较明显情况，如果在叶子上存在多个不符合条件的 span，从右向左的规则也会走一些弯路（这时就需要优化 CSS 选择器了）。但平均来说它还是更高效，因为大多时候，一个 DOM 树中，符合匹配条件的节点（如 .mod-nav h3 span）远少于不符合条件的节点。
希望我的回答可以帮到您哦
写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进程)上执行的，不占用主线程资源
