编写高效的 CSS答案

【问题标题】：Writing Efficient CSS编写高效的 CSS
【发布时间】：2009-08-14 18:00:00
【问题描述】：

好的，在另一个问题中正在讨论一些事情，并且提到了这个链接：

https://developer.mozilla.org/en/Writing_Efficient_CSS

在那篇文章中，他们说了一些我不知道的事情，但在我问他们之前，我应该问这个……这适用于 Firefox 解释的 CSS 吗？原谅我的菜鸟，但我不确定 Mozilla UI 是什么意思。（别伤害我！）

如果确实适用，当他们说：

避免使用后代选择器！

后代选择器是最 CSS 中昂贵的选择器。它是贵得吓人，尤其是如果使用选择器的规则在标签中或通用类别。经常是什么真正想要的是孩子选择器。后代的使用选择器在 UI CSS 中被禁止你皮肤的明确认可模块所有者。
* BAD - treehead treerow treecell { }
* BETTER, BUT STILL BAD (see next guideline) - treehead > treerow > treecell { }

后代选择器只是一个空格？那么孩子和后代之间有什么区别？ Child 是另一个元素中的一个元素，但这与后代不一样吗？在我写的时候，我想我可能已经弄清楚了。后代可能是孩子/孙子/曾孙/等？而child只有一层？

再次抱歉我的问题很愚蠢……只是想知道，因为我一直在我的网站的 CSS 中使用后代。但是，是的，如果这与 Firefox 无关，那么整个问题都是毫无意义的......

如果不是关于 Firefox，有没有人有文章的链接解释 Firefox 或一般浏览器的效率？

【问题讨论】：

是的。并且子选择器在 IE6 中不起作用，所以如果必须支持这种支持，那你就太牛了。

标签： html css performance mozilla

【解决方案1】：

后代可能是孩子/孙子/曾孙/等？而child只有一层？

是的，没错。由于孩子只能是一个深度，因此渲染引擎必须递归搜索以检查规则是否匹配的空间要小得多。

是的，那篇文章总体上是关于 Firefox 和浏览器的。其中的大部分（全部？）内容适用于任何页面渲染引擎。

【讨论】：

【解决方案2】：

首先 - 本文中的建议不适用于 html 页面 - 它们专门针对 Mozilla UI - XUL，所以这可能是 XUL 的最佳实践，但不是 html。

在一般的 HTML 页面上应用 CSS 是比加载页面时最快的事情之一。
此外，该文章可能会建议应用 css 规则的最快方法，但代价是什么？例如，他们建议每个规则不要超过一个类：

不好 - .treecell.indented { }
好 - .treecell-indented { }

这几乎是离谱。它可能会导致更快的 CSS，但谁在乎呢？假设您已经拥有 .treecell 和 .indented，遵循这些建议会导致复杂的逻辑、更难的维护、重复的 css 规则、更难的 JavaScript（这会花费更多CSS）等
他们建议不要使用 CSS 选择器的全部丰富性，而是用平面类替换这些选择器，这很可惜。

【讨论】：

实际上，文章将“treecell.indented”而不是“.treecell.idented”作为“BAD”。它给出了“p.indented”之类的通用示例，重点是“不要使用标签名称限定类分类规则”。它并没有说明每条规则有多个类。
@pw - 你是对的。我无法解释这是怎么发生的，但是这篇文章有足够多的例子来说明人们每天在 CSS 上所做的事情，这在 XUL 上是不推荐的。征得您的同意，我将保持原样。 :)

【解决方案3】：

...在我写的时候，我想我可能已经想通了。后代可能是孩子/孙子/曾孙/等？而child只有一层？

确实。

我可以在效率方面添加的一件事是：除非你是认真的，否则不要使用 *。随着规则的发展，它非常密集，大多数人只需指定他们真正想要定位的元素就可以逃脱。

【讨论】：

我在添加重置时确实知道了这一点。但是感谢您的重申！我什至没有意识到那篇文章中描述的一些普遍性是可能的，但也许这是为了更好，呵呵。
@Oli：我知道这是直接引用，但脏话被标记了，所以我把它删掉了。荒谬，我知道，但我认为这不会影响您的回答。

【解决方案4】：

“父>子”仅下降一级，而“祖先后代”可能下降一级或多级。

最好尽可能使用“#id”标签，这样可以减少 DOM 搜索。

【讨论】：

【解决方案5】：

UI CSS 用于设置浏览器内部的样式 - 设置对话框、扩展界面等。

后代和孩子是不同的，孩子更加具体，因此需要考虑的事情要少得多。

【讨论】：

【解决方案6】：

子选择器的问题在于它没有得到很好的支持。当然，这可能已在较新的 IE 浏览器上得到修复。

无论如何，在为网页编写 CSS 时，这并不是什么大问题。我怀疑您在页面加载中节省的几分之一秒甚至会被注意到。这篇文章似乎更针对为实际浏览器而不是网站编写内容的人。

【讨论】：

【解决方案7】：

O'Reillys "Even Faster Web Sites" 有一个完整的章节，题为“简化 CSS 选择器”。它引用了您在 Mozilla 上的链接。

我认为有两点值得牢记。

是的，如果你尽可能地这样做，你的 HTML 和 CSS 将会是一团乱糟糟的样式，而且由于增加了文件大小，效率可能会更低。由开发人员选择最佳平衡点。在编写时不要为优化每一行而苦恼，让它工作，然后看看有什么好处。
正如另一位评论者指出的那样，浏览器需要几毫秒才能弄清楚如何在页面加载时应用您的样式。然而，这可能产生更大影响的地方是 DHTML。每次更改 DOM 时，浏览器都会将整个样式表重新应用到页面。在这种情况下，许多低效的选择器可能会对您的页面产生明显的影响（感觉滞后/无响应）。

【讨论】：

【解决方案8】：

Google 的 Page Speed（Firefox/Firebug 插件）的文档包括一个good page on efficient CSS。

【讨论】：