CSS3笔记【不定时更新】

box-sizing

值	描述
content-box	这是由 CSS2.1 规定的宽度高度行为。 宽度和高度分别应用到元素的内容框。 在宽度和高度之外绘制元素的内边距和边框。
border-box	为元素设定的宽度和高度决定了元素的边框盒。 就是说，为元素指定的任何内边距和边框都将在已设定的宽度和高度内进行绘制。 通过从已设定的宽度和高度分别减去边框和内边距才能得到内容的宽度和高度。
inherit	规定应从父元素继承 box-sizing 属性的值。

【作为处理当有border或者padding的时候控制大小所用，当值为content-box的时候则设置的width、height大小为内容的大小不包括border与padding，当值为border-box时，设置的width、height为包括border的大小。】

CSS3 Gradient

【利用css3的特性做出渐变效果，包括线性渐变、弧度渐变等】

详见文章http://www.w3cplus.com/content/css3-gradient

CSS hack

	IE6	IE7	IE8	IE9	IE10	现代浏览器
*
+
-
!important
9
9

CSS 选择器优先级

选择器的优先权

 

 

解释：

1.  内联样式表的权值最高 1000；

2.  ID 选择器的权值为 100

3.  Class 类选择器的权值为 10

4.  HTML 标签选择器的权值为 1

CSS 优先级法则：

A  选择器都有一个权值，权值越大越优先；

B  当权值相等时，后出现的样式表设置要优于先出现的样式表设置；

C  创作者的规则高于浏览者：即网页编写者设置的CSS 样式的优先权高于浏览器所设置的样式；

D  继承的CSS 样式不如后来指定的CSS 样式；

E  在同一组属性设置中标有“!important”规则的优先级最大；

IE 浏览器下载或者渲染的顺序可能如下：

●   IE 下载的顺序是从上到下；

●   JavaScript 函数的执行会阻塞IE 的下载；

●   IE 渲染的顺序也是从上到下；

●   IE 的下载和渲染是同时进行的；

●   在渲染到页面的某一部分时，其上面的所有部分都已经下载完成（但并不是说所有相关联的元素都已经下载完。）

●   在下载过程中，如果遇到某一标签是嵌入文件，并且文件是具有语义解释性的（例如：JS脚本，CSS样式），那么此时IE的下载过程会启用单独连接进行下载。并且在下载后进行解析，如果JS、CSS中如有重定义，后面定义的函数将覆盖前面定义的函数。

●   解析过程中，停止页面所有往下元素的下载。样式表文件比较特殊，在其下载完成后，将和以前下载的所有样式表一起进行解析，解析完成后，将对此前所有元素（含以前已经渲染的）重新进行样式渲染。并以此方式一直渲染下去，直到整个页面渲染完成。

●   Firefox 处理下载和渲染的顺序大体相同，只是在细微之处有些差别，例如：iframe 的渲染。

CSS 选择器匹配

下面这个栗子，CSS选择器它是如何工作的？

.mod-nav h3 span {font-size: 16px;}

如果不知道匹配规则，可能的理解是从左向右匹配:先找到.mod-nav，然后逐级匹配h3、span，在这个过程中如果遍历到叶子节点都没有匹配就需要回溯，继续寻找下一个分支。

但事实上，CSS选择器的读取顺序是从右向左。

还是上面的选择器，它的读取顺序变成：先找到所有的span，沿着span的父元素查找h3，中途找到了符合匹配规则的节点就加入结果集；如果直到根元素html都没有匹配，则不再遍历这条路径，从下一个span开始重复这个过程（如果有多个最右节点为span的话）。

在某条CSS规则下（比如.mod-nav h3 span），会形成一条符合规则的索引树，树由上至下的节点是规则中从右向左的一个个选择符匹配的节点。索引树遍历的具体过程可以看寒冬大大的一段视频。

为什么从右向左的规则要比从左向右的高效？

 

假如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）远远远远少于不符合条件的节点。

jQuery从1.3版本开始使用的Sizzle引擎，它按照了CSS选择器的匹配规则（从右至左）进行DOM元素的查找与匹配（当然其中做了很多优化），性能得到了很大的提升。

CSS 渲染

版权声明：本文为博主原创文章，未经博主允许不得转载。