日期:2013-12-20 浏览次数:21171 次
原文地址:Writing Efficient CSS for use in the Mozilla UI
以下文档描述了使用在 Mozilla UI 中优化 CSS 文件的规则。第一部分是对于 Mozilla 款式系统分类规则的普通性讨论。在了解这个系统的基础上,后续部分包含了一些指南,书写可以利用这个款式系统实践优点的款式的指南。
款式系统把规则分为四大类。理解这些类是很重要的,由于对于规则的婚配来说他们是首先要考虑的。之后的段落中会使用“主选择符”这个说法。主选择符是指选择符最左边的部分(最终要婚配的那个元素,而不是它的祖先元素)。例如,在以下规则中:
a img, div > p, h1 + [title] {}
主选择符是 “img”, “p”, 和 “[title]“。
ID 选择符作为主选择符的规则。
例如:
如果一条规则有一个指定的 class 作为主选择符,就被归入此类。
例如:
如果主选择符不是 ID 或者 class,那么下一个类很可能就是 tag 分类。如果一条规则指定 tag 为主选择符,就被归入此类。
例如:
除以上分类之外都归入此类。
例如:
款式系统从最左边的选择符开始向左侧挪动来婚配一条规则。款式系统会不断向左婚配选择符直到规则婚配完毕或者由于出错停止婚配。
对于规则分类的第一步发生在主选择符类别基础上。这个分类的目的是把那些不需求浪费时间婚配的规则过滤出来。这是明显提升功用的重点。对于一个给定的需求婚配的元素,规则越少,款式的渲染越快。例如,元素有一个 ID,那么只要和元素 ID 婚配的 ID 规则会被检索。只要和元素的 class 婚配的 class 规则会被检索。只要和 tag 婚配的 tag 规则会被检索。全局规则总是会被检索。
确保规则不以全局分类结束
如果有一条款式规则是以 ID 选择符为主选择符的,就别再画蛇添足的加上标签名了。ID 都是独一的,因此加上标签名反而会无谓地拖慢婚配过程。(当有不同元素使用同一类名,而又需求动态地改变其中一个元素的类名来针对不同情况使用不同款式时是个例外。)
和以上规则类似,所有的类名也是独一的。标签和类名连缀的写法是一个惯例(但是,如果设计的变更使得需求改变标签就会有灵活性的问题,由于也需求改变 class — 最好选器具有严厉语义的名字,这种灵活性也是分离款式表的目标之一)。
拖慢系统最大的一个缘由是有太多的 tag 分类规则了。通过给元素添加类名,可以把这些 tag 类里的规则分一部分去class 分类,就可以不需求浪费时间来试图给一个标签婚配那么多的的规则了。
CSS 中,后代选择符(descendant)[注1]的耗能高的可怕,尤其是选择符的规则是在 tag 或者全局分类中。子选择符(child selector)则经常是真正所需。如果没有主题模块所有者的明确允许,UI CSS 中禁止使用后代选择符。
避免使器具有 tag 类规则的后代选择符。这会明显地添加婚配时间(尤其是这些规则会被多次婚配时)。