在 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 组成的选择器作为他们的选择器

例如:

1button#backButton {…} /* This is an ID-categorized rule */
2#urlBar[type="autocomplete"] {…} /* This is an ID-categorized rule */
3treeitem > treerow > treecell#myCell:active {…} /* This is an ID-categorized rule */

###class选择器

     它是由class作为他们key selector

例如: 

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

###标签选择器

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

例如:

1td {…} /* A tag-based rule */
2treeitem > treerow {…} /* A tag-based rule */
3input[type="checkbox"] {…} /* A tag-based rule */

###全局选择器

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

例如:

1[hidden="true"] {…} /* A universal rule */ 
2* {…}       /* A universal rule */
3tree > [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——————————————— 

原文地址:https://www.cnblogs.com/yupeng/p/2010473.html