写代码过程中,发现使用JQuery选择器时,$('div.tooltip')和$('.tooltip')的结果不一样,怀疑和选择器的代码逻辑有关(事后证明是代码的低级错误,但是从查找原因的过程中,学到了不少东西),于是去学习了下JQuery选择器引擎Sizzle,以及选择器的优先级。
1.Sizzle引擎
在jq1.3之前,选择器采用的是顺序的思维方式,在需要递进匹配时,例如$('div span'),执行的操作是先匹配div标签,再匹配div标签下的span标签,最后返回结果。而Sizzle采用了Right to left的匹配方式,先去搜寻页面所有的span标签,再去匹配父结点,如果是div,则压入数组,否则抛弃;最后返回结果。
从左到右解析和从右到左解析,性能上有多大的差异呢?
以$(‘div .clr > input[name="readme"] + p’)操作来分析:
"一般来说,HTML文档生成的DOM节点数是比较多的,而你书写的选择器selector绝大多数只能匹配到DOM树中较少的节点(否则就是你规则写得太不好了,一次性选择太多DOM节点会影响效率),因此需要有一种算法来快速判断出selector不匹配当前节点。
假设用从左到右的顺序解析:’div .clr > input[name="readme"] + p’,我们需要先找到所有div节点,然后从第一个div节点开始向下找class=”clr”的节点,一直深度下去,遇到不匹配的情况,就必须回溯到一开始搜索的div节点,然后去搜索下个div节点,重复这样的过程。这样的搜索过程对于一个只是匹配很少节点的选择器来说,效率是极低的,因为我们花费了大量的时间在回溯匹配不符合规则的节点。
如果换个思路,我们一开始过滤出跟目标节点最符合的集合出来,再在这个集合进行搜索,大大降低了搜索空间,这思路很赞:从右到左来解析选择器!
还是上边那个选择器,一开始我们把DOM树中所有的p节点找出来,紧接着我们判断这些节点中的前兄弟节点是否符合input[name="readme"]这个规则,这样就又减少了集合的元素,只有符合当前的子规则才会匹配再上一条子规则。
浏览器解析CSS的引擎就是用这样的算法去解析,同理,Sizzle引擎也是如此,并且在源码里边,它判断一个节点是否符合某个规则的行为定义为matcher。"
2.选择器的优先级
如果用1表示标签名选择器的优先级,用10表示类选择器的优先级,用100表示ID选择器的优先级;其余的选择器都是这三类选择器的扩展组合,通过把优先级相加来进行计算。在设置的属性相同时,优先级高的会覆盖优先级低的。
要写出简洁高效的CSS,要注意尽量不要在类选择器和ID选择器前加标签名,否则Sizzle引擎会进行多余的匹配;尽量少的使用层级关系,可以用class代替。