子鼠写了一篇《10条影响CSS渲染速度的写法与建议》，其中有几点我并不认同，疑问如下：
0、CSS的渲染速度
这一块我认为CSS不像JS用户有操作时就要重新渲染一次，基本上在加载时浏览器渲染过一次后，并不会再次渲染，所以如果对于首次加载时的速度问题来说还有一些道理。
但把页面的展示速度问题的重心定位原由于CSS的首次渲染速度问题是绝对不正确的，重点应该是各种元素的加载问题上！
而且除CSS外的其它元素的渲染问题相对于CSS渲染来说可能问题更多。
1、CSS选择符的遍历
“遍历”这个概念源自于程序开发，但对于浏览器来说，特别是关乎页面渲染速度的CSS，浏览器不会用这种很平常的“遍历”来进行后台的解析，而是应该专门做特别的优化，这一种从Chrome浏览器针对JS的V8引擎就可以看出。
2、CSS滤镜的效率
网站变灰代码效率最高是 html{filter:gray;} ，而不是子鼠提出的 body{filter: gray;} ，所以对于CSS滤镜的效率简单的归结原因是CSS滤镜而脱离CSS选择符也是不太全面而得出的观点。
3、绝对定位与float
基于WEB标准的网页布局无非“绝对（相对）定位布局”与“float布局”，在子鼠的文章中竞然提出两种都有问题，反而在推荐“Table页面布局”，这只能说是对于WEB标准及语义化上在认识层面上的一种偏差。
我在所从事大量的项目经验得出的结论是在页面的总体布局上使用float（主要是因为需自适应的原因），在比较精细小巧的局部使用“绝对（相对）定位布局”是一种行之有效的办法。
4、CSS的选择符深度
子鼠的文章中提出*{margin:0; padding:0}这个选择符深度最少的反而是效率最低的，推荐用body,li,p,h1{margin:0; padding:0}来单独处理。但又在CSS的选择符深度这里提出不能使用过于精确的CSS选择符，这一点十分的矛盾，因为按第一种观点是越精确越省效率，而第二种观点又在说越精确的选择符越不省效率的问题，对此令人十分的费解。
我个人认为CSS选择符越为精确，效率越高，因为浏览器只要精确的渲染定位到的元素即可，各元素的CSS耦合度低，效率高。
5、无效class
这一点不得不再说到HTML与CSS两种不同渲染的问题，要把YAHOO提出的14条网站优化建议中推荐把CSS要放在HTML的头部，那么，可以推断，如果放在HTML的底部，会出现页面没加载到CSS会先用HTML的默认CSS，然后再用加载到的CSS重新渲染。
因此，当HTML中有无效的CLASS时，CSS没有相应的，那么他还是用了HTML的默认CSS，所以效率上并没有问题。而当CSS中有无效的CLASS，HTML又没有调用这个CLASS时，HTML还是用了HTML默认的CSS，所以在效率上还是没有问题。
以上几点即是我对子鼠的文章的几点疑问，希望大家互相PK，讨论出事实的真相出来，谢谢。
都言之有理，4、5点我赞成这里的说法。其它的，没有深入研究，观望一下。
咱们一个一个来！
一、为什么我部分推荐用TABLE布局？单从网站效率为维护上来说，在现阶段，在实现一些效果时，并不是你说的完全语义化的结构就非常的合适；试想，一个兼容所有浏览器的一行三列自适应的布局，用简单的代码就能实现，为什么要用更多的HACK 或代码来实现呢？现阶段浏览器还没有统一标准的时候，我们就用大量的代码来实现，是不是代价太大了。 我并不是推荐用TABLE，只是说在实现部分效果时，用TABLE更合算。
二、绝对定位与FLOAT的问题？我的观点只是从文章的本身“速度”方面，不应该不应该用没有关系。 这方面你可以在UBUNTU下随便写点绝对定位的代码就可以比较一下性能有多差。 文章的内容不是写布局应该怎么布，哪些东西应怎么写，只是说明这些会对速度有影响。
三、CSS的选择符深度？*{} 和li,h1{}不是一回事； *{} 包括了 li 和 h1 ；*{} 作的事要比 li,h1多的多； CSS的路径别太深是指#abc .afads .fds .fsda{}；
二、UBUNTU这又不是主流的OS，我们不可能因为几个非主流的OS而失去了广大的WIN OS平台用户吧，这个有点为了芝麻丢了西瓜了。
三、CSS路径深不就是精确的控制你想要控制的元素么，并减少与其它CSS的耦合度，li h1相对于 * 是不是更加的精确一些，耦合度更小些呢？
四、CSS滤镜的效率？这一点方面用正确的选择符当然效率最高；但这和滤镜是两回事。单说滤镜是效率非常低的。
五、关于遍历，给你一个简单的例子，你去试一下！ *{filter: gray} 就加到你这个网页的头部，试一下！
六、关于无效的CLASS，这一点，我也提到了，但我提到的是他并不重要。这一点说实在的，我也没有非常好的例子或理论；你这里不能发到网址，我这里有一个国外的文章，你可以看一下； 我会QQ发给你；
最后，在写这篇文章时，我没有想到会有这么多人看或关注，说实话，文章写完后，我都没有从头到尾看一遍，文章从头到尾，是我想到哪就写到哪，没有细细地去理整体的逻辑。另外，你说的这些大多都是理论，而实际中，这些是我写的经验；float、绝对定位、*{}、滤镜这些全是我写了无数CSS的感觉和经验。 有些可能真的没有什么理论在里边。但实际他们确实有问题。
希望你接着砍我！
别人不砍，不会有进步！
五、你的例子正好是用了不合理的CSS选择符+CSS滤镜来说“遍历”，我要是 *{display:none;} 呢？
六、嗯，好的，我看看你的文章先。
嘿嘿，大家周末在家没事练习一下打字嘛。。。
另外关于FLOAT我的原话是这样的“float 的应用，这个东西我的感觉是如果使用不当，百分百有性能问题，而且还非常的大，但实在不知道怎么样能弄一个例子出来；这里只能建议大家如果不是很明白float是怎么工作的，还是少使用为妙。”；
而你提的是你们在项目是用到了，这是两回事！
另外，现在别扯太深的语义！现在很多的标签不同浏览器中的解释是不一样的，语义化的结构谁都知道非常好，非常的合理；但为了这些标签我们可以要写很多的代码，从维护方面来说，不是一个很好的解决方案。 个人认为当前阶段，只有去写适合的代码，而不是完全标准的代码，但心里要清楚，将来的方向是什么！
不赞同你这个看法，如果现在连根本的基础都没掌握好，以后怎么做呢。
如果你要方便那直接用PS切图导出页面多方便啊。
还有刚刚你也提到一个说三列的hack多，呃，不好意思，到目前位置我还未发现我用很多hack，用得最多的却是在对ie的定位（bottom），以及margin等问题上。
2位爷们儿 钢上了 – –
另外，现在别扯太深的语义！现在很多的标签不同浏览器中的解释是不一样的，语义化的结构谁都知道非常好，非常的合理；但为了这些标签我们可以要写很多的代码，从维护方面来说，不是一个很好的解决方案。 个人认为当前阶段，只有去写适合的代码，而不是完全标准的代码，但心里要清楚，将来的方向是什么！
不赞同你这个看法，如果现在连根本的基础都没掌握好，以后怎么做呢。
如果你要方便那直接用PS切图导出页面多方便啊。
还有刚刚你也提到一个说三列的hack多，呃，不好意思，到目前位置我还未发现我用很多hack，用得最多的却是在对ie的定位（bottom），以及margin等问题上。
每个网站都有自已适应的一种写法，考虑的因素有很多，例如：多人开发、后期维护等，网站的代码不可能是一个人在写；在实现一些效果时，为了标准等因素，代码有时会过于复杂； 你好好看一下我的观点，是写“适合的代码”，如果一个FW图片直接输出，是当前这件事非常适合的解决方案，那没有什么不好的。 代码有用户群，有生命周期，在有限的时间内，给有限的用户群，提供最小成本的代码，我认为是很好的解决方案。 如果没有这些考虑，我可能会把一些页面写的非常的标准，但我花的时间是成本呀？ 值吗？
一行三列的效果我几年前就写过，如果不考虑IE6以下，当然不用HACK了； 再说个较麻烦的例子，图片水平垂直居中，你不用表格能累死你，值吗？ 你不信，你写一写！
另外，现在别扯太深的语义！现在很多的标签不同浏览器中的解释是不一样的，语义化的结构谁都知道非常好，非常的合理；但为了这些标签我们可以要写很多的代码，从维护方面来说，不是一个很好的解决方案。 个人认为当前阶段，只有去写适合的代码，而不是完全标准的代码，但心里要清楚，将来的方向是什么！
不赞同你这个看法，如果现在连根本的基础都没掌握好，以后怎么做呢。
如果你要方便那直接用PS切图导出页面多方便啊。
还有刚刚你也提到一个说三列的hack多，呃，不好意思，到目前位置我还未发现我用很多hack，用得最多的却是在对ie的定位（bottom），以及margin等问题上。
“只有去写适合的代码，而不是完全标准的代码，但心里要清楚，将来的方向是什么！” 明白将来的方向，就是熟知基础！
为了用DIV而用DIV的人就是个白白，支持子鼠AAA
呃…关于选择符的深度问题…
还是建议别写的那么深…不然光是优先级的问题就能玩死你…
覆盖一个样式你还要考虑原来的优先级…= =!
从前就身受其害啊…………………
关于选择符深度的问题，没必要那么费神。处理好各模块样式的独立性即可，关键还是在于一个良性的样式管理结构。
很羡慕你俩的文采啊，不像我这种只会做不会说/写的类型。明白一些东西却说不出来，真压抑。
鄙人曾花了相当多的一段时间研究页面性能,子鼠的10条建议基本都是正确的
我觉得楼主在怀疑别人的观点的同时先自己试验一下
IE的滤镜有一个性能问题,在滚动条每滚动一次的时候会重新渲染,并且不会释放内存,子鼠说的全站变灰body{filter: gray;}就有这样的问题,至于楼主说应该是html{filter: gray;},这只是因为FF和IE对于html和body的理解上有差异造成的,楼主说的:把页面的展示速度问题的重心定位原由于CSS的首次渲染速度问题是绝对不正确的，重点应该是各种元素的加载问题上！
是完全错误的,页面在css加载完以前是不会进行渲染,所以才会有css文件一定要放头部的建议
至于float,我觉得确实容易引起问题,而且不闭合的话在某些情况下会出现溢出导致IE挂掉,所以不理解float工作模式的初学者的确是少用为秒
CSS的选择符深度
至于这个问题,虽然于性能影响甚微,不过既然ID是唯一的,干嘛要把父级写满呢,减写选择符也能活用继承,非常体现水平
我觉得楼主很多想法都是自己以为,既不做实验也不去看别人的实验结论,属于非常不负责任的行为
比如楼主推断，如果引用css文件放在HTML的底部，会出现页面没加载到CSS会先用HTML的默认CSS，然后再用加载到的CSS重新渲染。
完全是胡说八道,原因我在上面已经说明
你说的滚动一次就渲染一次，是在CSS用expression才会出现的情况，CSS滤镜并没有。
页面没有加载到CSS，是会用浏览器默认的CSS来渲染的。
你的其它留言基本没什么营养。。。
呃，你们那似乎很缺人啊。
这个老问题…，啥时候搬到北京来，绝对抛妻弃子来跟随～
已经变为无意义的口水战了…
不要打架哦！要和谐！
对于FLOAT浮动，看了这么多大家的讨论 似乎战战兢兢的
我们无法否认的是 div + float 比 table 单纯从页面布局和打开速度 都来得优秀
因为是闭合浮动的原因 而说这不适合初学者
我看后 忍不住笑了起来
我是不是可以这么理解
初学者们 CSS 很难 Div 很不容易掌握 你们不要学了
当然我并不提倡为了div 而div，但是如果说你们现在为了一点点的所谓的难度和不易掌握而table 的话
那只能是一种悲哀
OK
我的意见是
你们应该说
初学者们 float 不易掌握 下面的文章或分析 是我对float 的理解 希望看了对你们有帮助
在css study 路上 破荆前进
实在看不过去了。
冒一个泡。
1.现在这一个时代了，基于web标准的xhtml规范开发页面的优点还把节省带宽拿出来说事。我承认它的优越性，但是这个几乎可以忽略不计的优点拿出来说服意见相反者，没有什么可能性。
2.
这一个可真把我雷到了，等到大量数据的时候，维护的时候才叫一个麻烦呢。
子鼠说的效率单是考虑了开发阶段的成本，那维护时候呢？
说实话，对于一个熟手来说，基于division结构和table结构的布局在开发的情况下，几乎没有什么区别..
3.CSS的选择符深度这一个问题，很明显，子鼠只是通过臆想 - 我不是人身攻击。
我叫我拿证据出来也拿不出来，但是熟悉xml工作机制的话，自然会相信米随随的结论是正确的。
4.
这一个结论，真是足以让一个前端工作者心寒，彻底雷到了..
举例说<address />相对生僻，但是用样式表可以控制的，为啥不用，就因为不同的浏览器默认的解释不一样就不用了？
5.最后说一下，米随随为啥不换一下字体大小，我看得好累。