好的，在另一个问题中正在讨论的内容，并提到了这个链接：
https://developer.mozilla.org/en/Writing_Efficient_CSS
在那篇文章中，他们说了一些我不知道的事情，但在我问起之前，我应该问一下......这是否适用于Firefox解释的CSS？原谅我的noobness，但我不确定他们的意思是Mozilla UI。 （不要伤害我！）
如果它确实适用，当他们说：
避免使用后代选择器！
后代选择器是最多的 CSS中昂贵的选择器。它是 非常昂贵，特别是如果一个 使用选择器的规则在标记中 或通用类别。经常是什么 真正渴望的是孩子 选择。使用后代 选择器在UI CSS中禁用 明确批准你的皮肤 模块所有者。
* BAD - treehead treerow treecell { } * BETTER, BUT STILL BAD (see next guideline) - treehead > treerow > treecell { }
后代选择器只是一个空间？然后孩子和后代之间会有什么区别？孩子是另一个内部的元素，但与后代不一样吗？在我写作的时候，我想我可能已经弄明白了。后代可能是孩子/孙子/曾孙/等？孩子只有一个深吗？
再次抱歉我的问题愚蠢...只是想知道，因为我一直在我的网站中使用CSS的后代。但是，如果这不是关于Firefox，那么整个问题毫无意义......
如果它不是关于Firefox，是否有人链接到一篇解释Firefox或浏览器效率的文章？
答案 0 :(得分：7)
后代可能是孩子/孙子/曾孙/等？孩子只有一个深吗？
是的，确切地说。由于子项只能是一个深度，因此渲染引擎必须递归搜索以检查规则是否匹配，这个空间要小得多。
是的，那篇文章一般都是关于Firefox和浏览器的。其中的大多数（全部？）适用于任何页面渲染引擎。
答案 1 :(得分：6)
首先 - 本文中的建议是 不适用于html网页 - 它们专门针对 Mozilla UI - XUL ，所以它可能是XUL的最佳实践，但不适用于html。
在平均HTML页面上应用CSS是加载页面时最快的事情之一 此外，文章可能会建议应用css规则的最快方法，但代价是什么？例如，他们建议每个规则不要有多个类：
BAD - .treecell.indented {}
好 - .treecell-indented {}
这几乎是离谱。它可能会导致更快的CSS，但谁在乎呢？假设您已经拥有.treecell和.indented，则根据这些建议会导致复杂的逻辑，更难维护，重复的css 规则，更难的JavaScript（成本更高）更多的CSS）等。
他们建议不使用CSS 选择器的全部丰富性，并用平面类替换这些选择器，这是一种耻辱。
答案 2 :(得分：2)
......正如我写的那样，我想我可能已经弄明白了。后代可能是孩子/孙子/曾孙/等？孩子只有一个深吗？
确实
我可以在效率方面添加一件事：不要使用*除非你的意思是。随着规则的发展，它非常密集，大多数人只能指定他们真正想要定位的元素。
答案 3 :(得分：1)
“父母＆gt;孩子”只有一步，而“祖先后代”可能是一步或多步。
更好的是尽可能使用“#id”标签，以便减少DOM搜索。
答案 4 :(得分：1)
UI CSS用于设置浏览器内部的样式 - 设置对话框，扩展接口等。
后代和孩子是不同的，孩子更具体，导致更少考虑。
答案 5 :(得分：1)
子选择器的问题在于它不受支持。当然，这可能已在新的IE浏览器上得到修复。
在任何情况下，当为网页编写CSS时，它不会是那么大的交易。我怀疑你在页面加载中保存的秒数甚至会被注意到。这篇文章似乎更倾向于人们为实际的浏览器而不是网站编写内容。
答案 6 :(得分：1)
O'Reillys“Even Faster Web Sites"有一整章关于”简化CSS选择器“。它引用了你在Mozilla上的链接。
我认为有两点值得考虑。
是的，如果你尽可能地这样做，你的HTML和CSS将是一堆乱七八糟的样式，由于增加了文件大小，可能效率更低。开发人员可以选择最佳平衡点。在编写代码时不要为优化每一行而烦恼，让它工作然后看看什么是有益的。
正如另一位评论者指出的那样，浏览器毫秒需要弄清楚如何在页面加载时应用样式。但是，DHTML可以产生更大的影响。每次更改DOM时，浏览器都会将整个样式表重新应用到页面。在这种情况下，许多效率低下的选择器可能会对您的页面产生明显的影响（感知到的懒散/无响应）。
答案 7 :(得分：1)
Google的Page Speed（Firefox / Firebug插件）文档包含good page on efficient CSS。