佐吾

xhtml+css 前端开发

[译]高效的呈现CSS

原文:http://css-tricks.com/efficiently-rendering-css/
中文:http://www.vfresh.org/w3c/1034

只做重点翻译.

从右到左的解析

浏览器解析CSS的时候是从右至左,例如:ul > li a[title="home"]这个选择器中,浏览器首先解析是a[title="home"],这部分也被称为“选择器主键”,即最终将选择的元素。

ID选择符最高效,通配选择符最低效

从高效到低效,有四种选择符:ID,类,标签以及通配符。

css
css
#main-navigation { } /* ID (最快的) */
body.home #page-wrap { } /* ID */
.main-navigation { } /* 类 */
ul li a.current { } /* 类 *
ul { } /* 标签 */
ul li a { } /* 标签 */
* { } /* 通配符(最慢的) */
#content [title='home'] /* 通配符 */

结合上面说的“浏览器从右至左解析”,下面的这个选择器就不是那么高效了:

css
#main-nav > li { } /* 低于预计的效率 */

这让人非常的疑惑,我们原以为浏览器会先匹配最高效的ID,然后再去找那该死的子元素li。但事实是更该死的浏览器会先去找低效的li。

不要使用标签筛选

绝对不要这么用:

css
ul#main-navigation { }

ID是唯一的,所以没必要再用个标签,脱裤子放屁的事咱ITer不能做。
同样的,对于类(class)也应该尽量避免,除非你想实现同一类名根据标签来做不同的表现。

包含选择器是最烂的

David Hyatt曾说过:

CSS中最耗资源的就是包含选择器(Descendant Selectors),特别是这些选择器是标签或通配符时,资源开销会大的恐怖。

也就是说,这个选择器是相当的低效:

css
html body ul li a { }

墙内音:fuuuuuuck ie6

一个失败的选择器比一个成功的选择器更高效

我不确定这一条的实用性,因为在你的css里面出现着一堆一堆的无效的选择器,好像呃,非常的诡异。但还是得记录一下,当浏览器从右至左解析选择器的时候,一旦无法匹配就会立即停止解析。

写选择器的时候思考一下为什么

例如这个选择器:

css
#main-navigation li a { font-family: Georgia, Serif; }

只是用来申明字体类型(font-family),不必要指定的如此详细(除非你是重设font-family),可以通过继承的方式使之更高效:

css
#main-navigation { font-family: Georgia, Serif; }

全文主要内容译完
作者还提醒大家:不要为了优化css选择器效率而损失css的可维护性、语义化,这样就得不偿失了。本文只是希望你能认识到,css可以写的更好更漂亮。

另外,css选择器在一些JavaScript库中同样有用到,这些概念也同样适用;ID最高效,复杂、包含选择器这类是低效的。

 

阅读更多
个人分类: css
想对作者说点什么? 我来说一句

CSS高效开发实战

2015年12月31日 85.84MB 下载

书写高效的CSS

2011年12月22日 66KB 下载

没有更多推荐了,返回首页

不良信息举报

[译]高效的呈现CSS

最多只允许输入30个字

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭