在 Mozilla UI中书写高效的CSS

本文是翻译  https://developer.mozilla.org/en/Writing_Efficient_CSS

 目录：

1.样式系统选择器的分类

样式系统将规则断开为下面4中基本种类

（1）id选择器

（2）class选择器（类别）

（3）标签选择器（tag） 

（4）全局选择器

理解这些规则是很重要的，因为他们是选择器匹配的基本单元组成部分。

 在下面中我讲使用key selector  ，key selector 是选择器的最后的那个部分（它匹配自己，而不是匹配着祖先元素）

比如在下面的规则中：

a img, div > p, h1 + [title] {…} 

key selector   分别是img，p [title]

###ID选择器

它是由那些有一个 id selector 组成的选择器作为他们的选择器

例如:

1	button#backButton {…} /* This is an ID-categorized rule */

2	#urlBar[type="autocomplete"] {…} /* This is an ID-categorized rule */

3	treeitem > treerow > treecell#myCell:active {…} /* This is an ID-categorized rule */

###class选择器

     它是由class作为他们key selector

例如： 

1	button.toolbarButton {…} /* A class-based rule */

2	.fancyText {…}  /* A class-based rule */

3	menuitem > .menu-left[checked="true"] {…} /* A class-based rule */

###标签选择器

    如果没有id和class作为key selector，那么tag 选择器将作为候选。

例如：

1	td {…} /* A tag-based rule */

2	treeitem > treerow {…} /* A tag-based rule */

3	input[type="checkbox"] {…} /* A tag-based rule */

###全局选择器

    除了上面3种以外的选择器

例如：

1	[hidden="true"] {…} /* A universal rule */

2	* {…}       /* A universal rule */

3	tree > [collapsed="true"] {…} /* A universal rule */

样式系统如何匹配规则 

    样式系统匹配规则是从key selector开始的，然后往左移动（根据选择器寻找任何的祖先元素）。只要选择器的选择子树继续检查，样式系统继续往左移动直到它匹配到这个规则，或者是放弃，原因是匹配不到。

    理解这个规则最重要的观点就是过滤，这个分类的存在是为了过滤一些无关的规则（因此样式系统不会花费太多的时间去匹配他们）

    同时它也是提高性能的核心。对于一个给定的元素来说，越少的规则匹配，更快的样式将被取代。

举例来说，如果一个元素有一个id选择器，那么唯一的id将是匹配这个元素的id将被检查。如果是class，那么所有的元素包含class将会被查找，

如果是标签，那么所有能匹配该标签将被check，全局选择器的时候，所有的元素将被检查。

高效css的方式

（1）避免使用全局样式：

   不要使一个全局样式结束任何一个规则选择器

（2）id选择器永远不要使用class ，tag选择器限定 

   如果有一个id选择器，那么不要再添加class，tag选择器，因为id选择器是唯一的，添加class或者tag选择器只会无用的降低匹配进程。

例如：

BAD

button#backButton {…}

BAD
    .menu-left#newMenuIcon {…}

GOOD
    #backButton {…}

GOOD

    #newMenuIcon {…} 

（3）class选择器不要使用tag选择器限定

 理由同上，因为class 是唯一的，如果在前面添加了tag 选择器，那么他会一个一个的往左找，直到找不到。

例如：

BAD

treecell.indented {…}

GOOD

.treecell-indented {…}

BEST

.hierarchy-deep {…} 

（4）使用最明确的选择器（类别越少越好） 

 选择器很多也是一个很重要的降低效率的理由。通过增加class选择器，我们能够把这些规则细分，使最终花费的时间减少。

例如：

BAD

treeitem[mailfolder="true"] > treerow > treecell {…}

GOOD

.treecell-mailfolder {…}

（5）避免使用后代选择器

在css中，后代选择器是最花费时间的选择器。他是一个可怕的时间消耗，特别是如果是 标签选择器或者全局选择器。

 人们经常把这称为子选择器。在用户界面的css没有通过允许的是被禁止使用的。

例如：

BAD

treehead treerow treecell {…}

BETTER, BUT STILL BAD (see next guideline)

     treehead > treerow > treecell {…} 

（6）不要把标签选择器作为子选择器

在使用标签选择器的时候应该避免使用子选择器。这将动态的加长匹配的时间。 

例如：

BAD

treehead > treerow > treecell {…}

GOOD

     .treecell-header {…} 

（7）关于子选择器

如果能避免的话，就避免使用它。

特别的，子选择器经常被用作RDFtree 

BAD

     treeitem[IsImapServer="true"] > treerow > .tree-folderpane-icon {…} 

GOOD

    .tree-folderpane-icon[IsImapServer="true"] {…} 

（8）关于继承

学习一下那些事可以继承的，并且使用它们。

例如：在XUl工具里面是很明确的建立父元素的list-style-image or font 属性，这些将渗入到下面的无名的元素中，直接指向一些无名的内容是浪费时间的。

case：

BAD

#bookmarkMenuItem > .menu-left { list-style-image: url(blah) }

GOOD

     #bookmarkMenuItem { list-style-image: url(blah) } 

在上面的例子中，目的是用所有的匿名元素使用 list-style-image属性，同时次规则将结束在一个id选择符中，这该是多么的高效啊。。

记住：所有的元素都具有相同的class，特别是匿名选择符

上面的bad 例子中强迫所有的菜单按钮去探测包含菜单的项，因为有很多的菜单项，这是十分浪费时间的。相反的 good只限制测试

bookmarks menu 。

—————————————end———————————————