总结了部分所学、所听、所看、所问的一些CSS写作经验，它们与渲染效率及所占用消耗的资源有一定的关联。部分为自己理解所写，不排除会有错漏，欢迎提供更好的意见。
备注：第7~11题的理解来自原文：Writing_Efficient_CSS译文：书写高效的CSS


   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的板块需要重复平铺250000(贰拾伍万)次。提高背景图片渲染效率跟图片尺寸及体积有关，最大的图片文件体积保持约70KB。
          * 不赞成 - 宽高8px以下的平铺背景图片
          * 建议用 - 衡量适中体积及尺寸的背景图片

   5.
      IE的滤镜

      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"] { }



演绎原文：http://blog.gulu77.com/?p=47

[ 本帖最后由 phantom 于 2008-7-20 17:13 编辑 ]

有点意思..

有收获

对这方面研究不多，不过有一部分不大认同：
例如：display与visibility的差异。

引用:

在编写一些常见的动态效果时，一般使用CSS的display来切换可见性。很不幸，这也会产生reflow. 把元素置为display:none，相当于把这个元素的frame销毁了，再置回非none时，需要重新构造frame，这就产生了reflow. 而另外一个切换可见性的属性visibility则不存在reflow问题，置为visibility:hidden的元素的frame并没有销毁，需要显示的时候其实就是一个绘制（上面提到的动作第三步）过程而已，没有reflow，因此效率会更高。如果你看过一些JavaScript库／框架的源码，会发现它们大量使用visibility而不是display，道理应该如此。

上面这段文字引之Realazy 的关于reflow，这时一片关于mozilla的CSS渲染源码分布位置和渲染流程的文章，但ie下如何渲染就不太了解。文章连接：http://www.blueidea.com/tech/web/2007/4950.asp

可以说在某环境下这是一个矛盾，我所说的没错，Realazy表达的也没错。

visibility:hidden; 一开始就把所占用的物理空间渲染了出来，而看不见内容。
display:none;保持隐藏，只有改变值(none改为block)，才开始渲染占用的物理空间。

为何建议用display:none;有三个解释
1.  -----------------------------------------------------------------------------------------
例如下面的选项卡：

图例有四个板块内容，现在只显示了一个板块内容
用visibility -- 浏览器把四个板块都渲染出来。用户经过四次或以上选项卡才值回票价。
用display:none; -- 浏览器只渲染了一个板块。用户经过不多于四次选项卡，用display:none;就占有优势了。

2.--------------------------------------------------------------------------------------------
按照2.《display与visibility的差异》的解释，在页面中分别用display与visibility隐藏内容，必定是display渲染效率占优势。

3.--------------------------------------------------------------------------------------------
如上图， visibility 一开始就会渲染四个物理空间，而它们显示的位置会变得难以控制，要使用更多的CSS控制才得以还原效果。



在某些特定环境下visibility会比display:none;占优，但我认为是少数的。

以上结论愧为个人观点不排除有误解

[ 本帖最后由 gulu77 于 2008-7-5 00:24 编辑 ]

你所说得例子我觉得只是反映了使用display更容易实现效果。
但渲染效率上并没有证明到什么。
visibility的流程是：看得见→看不见→看得见（元素已存在，不用整个元素重新渲染）
display的流程是：有→无→有（整个元素不停重新渲染）
渲染效率方面显而易见！visibility更好
还有ls的例子的解析1，看不懂！
纯粹个人想法，不过同时我认为display比较好用。

[ 本帖最后由 zidanezhicong 于 2008-7-4 23:12 编辑 ]

我想知道实际运用中究竟有多少差异。。。。。。

很好的问题，其实我们都不大清楚浏览器的渲染流程是如何，也没有条件测试效率的差异，很多想法都是想当然。毕竟没什么说服力！在这方面研究的人也太少了！
大家有兴趣可以看看这篇“形象化的reflow”，蛮有意思的！
http://www.aoao.org.cn/blog/2008/05/reflow/

有自己的見解很好，不過對於一些效率上的問題確實需要有條件做測試后得出大概數據才好

多谢楼主总结，也希望多点类似的讨论。

有收获..谢谢楼主分享

對於一些效率上的問題確實需要有條件做測試后得出大概數據才好,赞同楼上斑斑的意见
对lz的观点不全部接收,但强烈支持研究精神,占位和大家一起研究一下先

感觉有些都是些习惯问题 也许对实际开发的帮助不会太大...

有点意思，学习了！

引用:

原帖由 W3CSS 于 2008-7-5 09:07 发表
我想知道实际运用中究竟有多少差异。。。。。。

根据我的估计应该是几万分之一毫秒吧...

  只是估计,不要给我拍砖...也不要和我争.  因为这都是没意思的事.[跟我争是不是万分之一毫秒这事]

谢谢楼主。受教了。

好像比以前更深入些了.呵呵.

这个渲染效率是针对用户端电脑的，现在客户端绝大多数的电脑的配置来说，因楼主所说的原因造成的渲染效率下降几乎用户都感觉不到。
大多游戏都采用了富客户端的做法，因此对于楼主所说的渲染效率我的看法，在不影响浏览效率的情况下，优先考虑服务器带宽及服务器性能方面。

不错
  学习了~~！

看上去有点道理。

自从家里机器坏了  好久没来蓝色了。。

关于第7条以下的几条，有些多加一些选择符并非为了一些无用的理由。
毕竟 button#backButton {} 的优先级比 #backButton {} 要高,而有些特殊的要求确实用到他们

不过话又说回来。。除非必要，还是不用，毕竟绕来绕去起码优先级的问题就能把人给陷进去

引用:

原帖由 lijun198296 于 2008-7-7 10:38 发表
这个渲染效率是针对用户端电脑的，现在客户端绝大多数的电脑的配置来说，因楼主所说的原因造成的渲染效率下降几乎用户都感觉不到。
大多游戏都采用了富客户端的做法，因此对于楼主所说的渲染效率我的看法，在不影响 ...

我正想说这个意思。

谢谢，收了，慢慢看！

对楼上部份问题的见解：

考虑全局，我们不能确保每个客户端都拥有良好的配置或环境。
而且作为页面制作人员，尽力提高客端性能是理所当然的事情。
不管对性能优化程度有多少，应该尽一切可能提高用户体验...

有一些问题，在效率上显而易见
要弄一个测试这效率的条件恐怕好难。

这也是我关心的问题，做了这么久，究竟怎么样效率高一直是一知半解，今天看了挺有收获，慢慢吸收

说真的  有些 不敢苟同
除了 display 上面老兄以说过了
还有很多  因为这一点点效率 还要给 页面添加很多 没必要的 class或者id 也不一定好到那里去，还有通配符的问题，全局的匹配减少了很多不必要的麻烦，特别是你不可能完全了解 每个浏览器的兼容性方面的问题，会带来很多的麻烦。
你要知道  做国外的项目，哪怕一个px给对项目来说都是致命的
很有很多 就不一一举例了 。。
我只能说  楼主说的这些过于片面

引用:

原帖由 gulu77 于 2008-7-8 16:36 发表
对楼上部份问题的见解：

考虑全局，我们不能确保每个客户端都拥有良好的配置或环境。
而且作为页面制作人员，尽力提高客端性能是理所当然的事情。
不管对性能优化程度有多少，应该尽一切可能提高用户体验...

你说的很有道理，但是考虑全局应该包括下面的因素，服务器的带宽，服务器处理请求的能力，客服端带宽，客服端电脑的性能等等。
对于你说的使用滤镜和通配选择符相关方面的意见我很赞成。
关于图片方面我认为下载一张大图片所花费的时间客户很多情况是可以感知的，而一条线平铺一千次所用的时间客户基本是察觉不到的。

很好~~~学了很多

我还是比较期待绝对定位对浏览器效率的影响