渲染机制详解编程语言

1、十六进制的颜色值对位数与大小写

编写十六进制颜色值时你可能会用小写字母或省略成3位数，关于这写法没找到确实的数据证明对浏览器的渲染效率是否有影响，但十六进制的颜色
值默认标准是大写及6位数标注。在未知情况下不希望冒险而降低了渲染的效率。

* 不赞成 – color:#f3a;

* 建议用 – color:#FF33AA;

2、display与visibility的差异

他们用于设置或检索是否显示对象。display隐藏对象不保留物理空间，visibility为隐藏对象保留占据的物理空间。当浏览器渲染被占据的物理空
间时，会有所消耗资源。

* 不赞成 – visibility:hidden;

* 建议用 – display:none;

3、border:none;与border:0;的区别
和display与visibility的关系类似，分别不保留与保留空间。更多的是border:0;尽管可以隐藏掉边框，但它会为你保留border-color/border-
style的使用权。

* 不赞成 – border:0;

* 建议用 – border:none;

4、不宜过小的背景图片平铺
一张宽高1px的背景图片，虽然文件体积非常之小，但渲染宽高500px的板块需要重复平铺2500次。提高背景图片渲染效率跟图片尺寸及体积有关，最
大的图片文件体积保持约70KB。

* 不赞成 – 宽高8px以下的平铺背景图片

* 建议用 – 衡量适中体积及尺寸的背景图片

5、IE的滤镜 (3lian.com)
IE的滤镜除了比较消耗资源外也有兼容性问题。当中有令PNG透明的滤镜，可采用GIF或JPG似透非透的办法来避免使用此滤镜。建议只在IE6应用GIF
透明，因为IE7以上已经支持了PNG透明。

* 不赞成，滥用IE滤镜因为消耗资源外也有兼容性问题。

* 建议用，最好选择其它方法能避免使用滤镜。

6、*{ margin:0; padding:0;}避免浏览器样式差异
*号通配符把所有标签都初始化一遍，浏览器的渲染消耗一定的资源。有部分在标签在不同浏览器上几乎无差异，或是某些已经不推荐使用的标签(
为你不会去用它)，它们不需通配符要重新初始化一遍这样做能节省一点资源。

* 不赞成，使用*号通配符

* 不赞成，div span button b table等标签纳入通配符控制内外填充样式

* 建议用，有选择性地使用通配符控制内外填充样式。

7、不要添加额外的标签来描述class或id
如果你有一个选择器是以id作为关键选择符，请不要添加多余标签名上去。因为ID是唯一的，你不要为了一个不存在的理由而降低了匹配的效率。

* 不赞成 – button#backButton { }

* 不赞成 – .menu-left #newMenuIcon { }

* 建议用 – #backButton { }

* 建议用 – #newMenuIcon { }

8、尽量选择最特殊的类来存放选择器
降低系统效率的一个最大原因是我们在标签类中用了过多的选择符。通过添加 class 到元素，我们可以将类别进行再细分为 class 类，这样就不
为了一个标签浪费时间去匹配过多的选择符了。

* 不赞成 – treeitem[mailfolder=”true”] > treerow > treecell { }

* 建议用 – .treecell-mailfolder { }

9、避免子孙选择符
子孙选择符是CSS中最耗资源的选择符。他真的是非常的耗资源，尤其是在选择器使用标签类或通用类的时候。很多情况中，我们真正想要的是子选
择符。除非有明确说明，在 UI CSS 中是严禁使用子孙选择符的。

* 不赞成 – treehead treerow treecell { }

* 好一点，但还是不行(参照下一条) – treehead > treerow > treecell { }

10、标签类中不要包含子选择符
不要在标签类中使用子选择符。否则，每次元素的出现，都会额外地增加匹配时间。（特别是当选择器似乎多半会被匹配的情况下）

* 不赞成 – treehead > treerow > treecell { }

* 建议用 – .treecell-header { }

11、留意所有子选择符的使用
小心地使用子选择符。如果你能想出一个的不使用他的方法，那么就不要使用。特别是在 RDF 树和菜单会频繁地使用子选择符，像这样。

* 不赞成 – treeitem[IsImapServer=”true”] > treerow > .tree-folderpane-icon { }

请记住 RDF 的属性是可以在模板中被复制的！利用这一点，我们可以复制那些想基于该属性改变的子 XUL 元素上的 RDF 属性。

* 建议用 – .tree-folderpane-icon[IsImapServer=”true”] { }

从右到左
浏览器如何读取你的CSS选择器有一个很重要的原则，那就是它们从右到左读取。这意味这像 ul > li a[title=”home”] 这样的选择器，a[title=”home”] 将是最先被读取的。这一部分通常被称为 “key selector” （可否称为“目标选择器” -_-!）选择器的最后一部分，也是被选择的标签。
ID’s 是最有效率的，通用符是最慢的
有四种目标选择器：ID, class, tag和通用符。看下他们各自的效率如何:

#main-navigation { }

body.home #page-wrap { }

.main-navigation { }

ul li a.current { }

ul li a { }

* { }

#content [title=’home’] 然后我们结合从右到左和目标选择器的概念，我们可以知道下面这个选择器并不高效： #main-nav > li { }

尽管这让人有点费解……因为ID’s是最高效的，浏览器可以通过ID迅速的找到 li。但事实是，li 标签是被先读取的。

不要用标签修饰死也不要像下面这样干：ul#main-navigation { }

ID’s 是唯一的，所以不需要用标签修饰，这只会让它更低效。

如果你可以避免的话，也不要用它修饰 class 。class 不是唯一的，所以理论上你可以把它用在不同的标签。如果你愿意的话，你可以用标签控制不同的样式，这样你可能需要标签修饰（比如：li.first），但这样做的人很少，所以，don’t .绝对没有比用后代选择器更糟糕的做法了
后代选择器是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放弃语义和可维护性。

Link ： http://blog.sina.com.cn/s/blog_77a4568a0101d6di.html

原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/17313.html

渲染机制详解编程语言

相关推荐

发表回复