编写高效的CSS

好了，所以在另一些问题正在讨论，并提及此链接：编写高效的CSS

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或浏览器一般？

来源

2009-08-14 Ian Storm Taylor

是的。而且，儿童选择器在IE6中不起作用，所以如果这种支持是必须的，那么你几乎是骨子里的。 – jason 2009-08-14 18:03:40

首先 - 本文中的建议是不是HTML页 - 他们是专门为Mozilla的UI - XUL，所以它可能是XUL最佳实践，而不是HTML。

在平均HTML页面上应用CSS是加载页面时发生的最快的事情之一。
另外，文章可能会建议应用css规则的最快方式，但是花费多少？例如，他们建议没有按规则不止一个类：

BAD - .treecell.indented {}
GOOD - .treecell缩进{}

这几乎离谱。它可能会导致更快的CSS，但谁在乎？假设你已经有.treecell和.indented，以下这些建议会导致复杂的逻辑，更难维护，复制CSS规则较硬的JavaScript（花费了很多更多的CSS）等
他们建议不使用全CSS选择器的丰富性和用平面类替换这些选择器，这是一种耻辱。

来源

2009-08-14 18:33:54 Kobi

实际上，文章给出了“treecell.indented”而不是“.treecell.idented”作为“BAD”。它给出了一个类似“p.indented”的通用示例，并且要点是“不要限定具有标记名称的类分类规则”。它没有说每个规则有多个类别。 – 2009-11-13 04:44:57

@pw - 你是对的。我无法解释这是怎么发生的，但文章中有足够的例子说明人们每天在CSS上做什么，这在XUL上是不推荐的。经你的允许，我会留下答案。 :) – Kobi 2009-11-13 10:10:16

后裔可能是孩子/孙子/曾孙/等？孩子只有一个深？

是的，正好。由于孩子只能是一个深度，因此渲染引擎必须通过递归搜索来检查规则是否匹配。

是的，该文章是关于Firefox和浏览器一般。大多数（所有？）的内容适用于任何页面渲染引擎。

来源

2009-08-14 18:01:55 Amber

“父母>孩子”只是一步下降，而“祖先后裔”可能是一个或多个步骤。

更好的方法是尽可能使用“#id”标签，以便减少DOM搜索。

来源

2009-08-14 18:02:33

的UI CSS是一种样式浏览器的内部 - 设置对话框，扩展接口等

后裔和儿童是不同的，孩子们更具体的，并导致更不必考虑。

来源

2009-08-14 18:02:47

...在我写作时，我想我可能已经弄明白了。后裔可能是小孩/孙子/曾孙/等等？孩子只有一个深？

确实。

有一件事我可以对事物的效率方面补充说明的是：不要使用*，除非你是说真的。规则非常密集，大多数人只能指定他们真正想要的元素。

来源

2009-08-14 18:09:03 Oli

我确实在添加重置时学到了这一点。但是，谢谢重申！我甚至没有意识到那篇文章中描述的一些普遍性是可能的，但也许那是更好的嘿嘿。 – 2009-08-14 18:14:05

@Oli：我知道这是一个直接的引用，但亵渎标记了，所以我编辑了它。可笑，我知道，但我认为这不会对你的答案带来任何影响。 – 2009-08-14 19:56:58

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

在任何情况下，对网页编写CSS时，它不会是大问题。我怀疑你在页面加载中保存的秒数会被注意到。这篇文章似乎更倾向于人们为真正的浏览器写东西，而不是网站。

来源

2009-08-14 18:18:12 Karl

O'Reillys“Even Faster Web Sites"对这个题目一整章‘简化CSS选择’，它引用您在Mozilla的链接。

我觉得有两点是值得铭记。

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

来源

2009-08-14 20:53:00

Google的Page Speed（Firefox/Firebug附加组件）文档包含good page on efficient CSS。

来源

2009-11-13 05:02:12

编写高效的CSS

回答

相关问题