QWrap Selector解密之三：matchesSelector
w3c的selector-api2标准已经提供了matchSelector的相关条文：
http://dev.w3.org/2006/webapi/selectors-api2/#matchtesting
[Supplemental]
interface Element {
boolean matchesSelector(in DOMString selectors, in optional Element refElement);
boolean matchesSelector(in DOMString selectors, in sequence<Node> refNodes);
};
};
Firefox也有个对应的方法：https://developer.mozilla.org/en/DOM/Node.mozMatchesSelector，不过，它相对于标准的matchesSelector，明显少了一个refElement的参数。
QWrap也有一个与标准几乎一致的方法Selector.filter。
* 用一个css selector来过滤一个数组.
* @method filter
* @static
* @param {Array|Collection} els: 元素数组
* @param {string} sSelector: 过滤selector，这个selector里的第一个关系符不可以是“+”“~”。
* @param {Element} pEl: 父节点。默认是document
* @returns {Array} : 返回满足过滤条件的元素组成的数组。
*/
Selector.filter = function(els, sSelector, pEl) {
//...
}
与标准相比，不同点有：
1。标准方法叫matchSelector，这个方法叫filter，用法不同。
2。sSelector是相对于参考元素的，而不是document，所以，也不必先写:scope伪类。
3。sSelector的起始关系符需要是亲子关系或后代关系，而不允许是兄弟关系。即，不可以是“+”“~”
这个方法的思路大略是：取出els[i]，然后用sSelector来作路线指导，寻找关系路线，一直找到pEl，找得到，则通过过滤，反之则不通过。
例如：html结构是这样的：html>body>div#div1.div1>div#div2.div2>span#span1.span1，通过下表我们看下各种情况下的执行过程：
| 序号 | selector | 处理顺序 |
| 1 | filter([span1],'span.span3',body) | 先判断span1本身是否满足"span.span3"，NG 结论：未通过过滤 |
| 2 | filter([span1],'span.span1',body) | 先判断span1本身是否满足"span.span1"，OK 再判断body与span1是否是后代关系，OK 结论：通过过滤 |
| 3 | filter([span1],'>span.span1',div2) | 先判断span1本身是否满足"span.span1"，OK 再判断div2与span1是否是亲子关系，OK 结论：通过过滤 |
| 4 | filter([span1],'>span.span1',body) | 先判断span1本身是否满足"span.span1"，OK 再判断body与span1是否是亲子关系，NG 结论：未通过过滤 |
再看更多层次时，对应的执行过程：
| 序号 | selector | 处理顺序 |
| 11 | filter([span1],'div span',body) | 先判断span1本身是否满足"span"，OK 通过span1寻找"div "，即找div祖先，得到div2，OK 再判断body与div2是否是后代关系，OK 结论：通过过滤 |
| 12 | filter([span1],'table span',body) | 先判断span1本身是否满足"span"，OK 通过span1寻找"table "，即找table祖先，NG 结论：未通过过滤 |
| 13 | filter([span1],'html span',body) | 先判断span1本身是否满足"span"，OK 通过span1寻找"html "，即找html祖先，上寻时通过body时还没找到，NG 结论：未通过过滤 注：虽说上寻到body上层可以找到html，但是这也不符合参考body的“ html span” |
| 14 | filter([span1],'>div span',body) | 先判断span1本身是否满足"span"，OK 通过span1寻找"div "，即找div祖先，得到div2，OK 再判断body与div2是否是亲子关系，NG 回溯，发现可以继续从div2再向上找div，找到div1，OK 再判断body与div1是否是亲子关系，OK 结论：通过过滤 注：这里有一个回溯的过程，即向上寻路时，如果分支不通，需要回退再寻他路。 注：sizzle没有处理这种回溯的情况，所以某些情况下会出现错误，参见： http://www.cnblogs.com/rubylouvre/archive/2011/01/24/1942818.html#2018177 |
| 15 | filter([span1],'>div>span',body) | 先判断span1本身是否满足"span"，OK 通过span1寻找"div>"，即找div父亲，得到div2，OK 再判断body与div2是否是亲子关系，NG 结论：未通过过滤 想一想：为什么这里不需要回溯？？？ |
| 16 | filter([span1],'table div span',body) | 先判断span1本身是否满足"span"，OK 通过span1寻找"div "，即找div祖先，得到div2，OK 通过div2寻找"table "，即找table祖先，NG 结论：未通过过滤 想一想：为什么这里不需要回溯？？？ |
| 17 | ... | ... |
注，为方便理解，以上例子中都没有提到“+”“~”关系符，有兴趣的同学可以举一反三一下。
由于回溯是一件很耗cpu的事，所以，我们需要尽量不做无谓的回溯。而是否需要回溯，或在哪一步需要回溯，这个又需要通过整个selector的所有关系符来判断。
sizzle使用候选集加映射集的方式来实现query，这导致他在作是否回溯的决定时，没法全盘考虑这个selector中的所有关系符以及当前关系符的位置，他很难作这个决定。现在的情形看来，他索性偷了个懒，任何情况下都不作回溯了。----事实上，需要回溯的情况在现实中很少见，所以，Sizzle没有考虑，也很少有人发现这个问题。
QW.Selector里关于，把“ ”“~”当作需回溯关系符，而把一个selector中的所有关系符串成relationsStr，再通过“(/[+>~] |[+]~/.test(relationsStr))”来判断是否需要回溯。
例如：
“ table div span”的关系符串起来是三个空格，(/[+>~] |[+]~/.test(relationsStr))的结果是false，即，不需要回溯；
“>div>span”的关系符串起来是“>>”，不需要回溯；
“>div span”的关系符串起来是“> ”，需要回溯；
......
明白了matchesSelector的思路，即“按selector寻路径，将el与pEl连起来”，之后，再看实现代码就会很清晰了。
事实上，由于这个方法的sSelector参数里可能有“,”并联关系符，所以，真正实现filter的函数是一个内部函数： (注意一下，参数与filter的参数顺序不一致，而sltors是已经将sSelector拆成了关系符与自选器的配对数组)
判断一个长辈与子孙节点是否满足关系要求。----特别说明：这里的第一个关系只能是父子关系，或祖孙关系;
*/
function filterByRelation(pEl, els, sltors) {
//...
}
附：QWrap网址：http://www.qwrap.com