W3C Selector API將為JavaScript開發注入新活力

今天，向大家介紹DOM指令碼編程領域一項令人激動的進步——W3C Selector API。迄今為止，在使用DOM2級API的前提下，要想從DOM中取得HTML元素，只能使用document.getElementById，或者使用document.getElementsByTagName然後再手工編碼進行篩選。隨著CSS的普及，JavaScript開發人員不斷提到一個顯而易見的問題：“為什麼瀏覽器不能提供一種快捷方法，用來選擇與CSS選擇符匹配的HTML元素呢？”

於是，上述Selector API定義了querySelector和querySelectorAll方法，它們就以CSS選擇符為參數，分別返回匹配的第一個元素和所有匹配元素的StaticNodeList（靜態節點列表）。這兩個方法既可以通過document對象調用，以便在整個文檔範圍內查詢目標元素，也可以通過個別的HTML元素調用，以便只在該元素的後代元素中查詢目標元素。

下面我們看一個簡單的HTML樣本，以此示範如何使用Selector API：

1. <ul id="menu">
2.   <li>
3.     <input type="checkbox" name="item1_done" id="item1_done">
4.     <label for="item1_done">bread</label>
5.   </li>
6.   <li class="important">
7.     <input type="checkbox" name="item2_done" id="item2_done">
8.     <label for="item2_done">milk</label>
9.   </li>
10.   <!-- 更多清單項目 -->
11. </ul>

我們的任務是通過指令碼選中所有類名為“important”的清單項目中的複選框（checkbox）。如果使用DOM2級API的方法，可以這樣來做：

1. var items = document.getElementById(
2.     'menu'
3.   ).getElementsByTagName(
4.     'li'
5.   );
6. for(var i=0; i < items.length; i++) {
7.   if(items[i].className.match(/important/)) {
8.     if(items[i].firstChild.type == "checkbox") {
9.       items[i].firstChild.checked = true;
10.     }
11.   }
12. }

而使用新的選擇符API，則可以將上面代碼簡化為：

1. var items = document.querySelectorAll(
2.     '#menu li.important input[type="checkbox"]'
3.   );
4. for(var i=0; i < items.length; i++) {
5.   items[i].checked = true;
6. }

是不是更簡單方便了？注意，querySelector和querySelectorAll方法還支援組合選擇符——即由逗號分隔的多個選擇符。目前，將會支援Selector API的瀏覽器包括Safari3.1、IE8 beta、Firefox3.1。Opera也在積極添加對該API的支援。

假如讀者擅長使用各種JavaScript庫，那麼心裡可能會暗自嘀咕：“這些我通過庫早就能做到了呀？”事實上，很多人使用各種JavaScript庫的原因在很大程度上恰恰是因為這些庫實現了通過CSS選擇符的查詢機制。最近，由於這些庫作者們共用了他們的技術，我們發現CSS選擇符查詢速度又有了明顯的提升。那麼，使用Selector API還有什麼必要呢？一言以蔽之：速度——本地實現的優勢就是速度！而且，所有這些JavaScript庫都非常看重這一點。jQuery和Prototype正在向使用Selector API的路線上靠攏，而Dojo Toolkit、DOMAssistant和base2則已經在使用該API了。

這3個庫之所以能首批利用該API是有原因的。Kevin在他的部落格文章“Is Your JavaScript Library Standards Compliant?（你的JavaScript庫與標準相容嗎？）”曾專門討論過這些問題。由於Selector API要求使用標準的CSS選擇符，因此如果瀏覽器不支援某種選擇符，那麼就無法使用該選擇符。這些已經開始利用Selector API的庫都是原先只支援標準CSS選擇符的。對於這些庫而言，支援該API（幾乎）就相當於添加如下代碼：

1. if(document.querySelector) {
2.   return document.querySelector(selector);
3. } else {
4.   return oldSelectorFunction(selector);
5. }

但是，那些支援自訂選擇符的庫要支援Selector API則遠沒有那麼簡單。首先，如果開發人員已經在自己的項目中大量使用了自訂的CSS選擇符，那麼要想通過該庫獲得速度提升會很困難，因為這些庫必須使用其預設選擇符而不能使用Selector API。其次，即使這些庫採取某種措施解決了使用自訂選擇符的問題，從而支援了Selector API，但該庫也必須面對體積增大的風險。

理想的狀況下，Selector API是想鼓勵人們使用標準CSS選擇符，放棄使用自訂選擇符。事實上，如果新版的瀏覽器都能做到足夠好，而且新Selector API的效能提升也足以令人側目，那麼自訂選擇符功能很可能就會自動轉移到輔助庫中，而且只在處理遺留代碼的相容性問題時才會用到。

我個人認為，Dean Edwards的base2庫實現得最好的。因為base2完全實現了該API，也就是說，開發人員使用base2編寫JavaScript時盡可以使用標準的API方法——因為base2隻在瀏覽器不支援標準API時，才會建立querySelector和querySelectorAll方法。這已經是一種非常理想的狀態了。但是，不管怎樣base2還是在其自訂選擇符功能中實現了非標準的“!=”屬性選擇符（顯然是迫於同行的壓力），因此在這一點上也有所失分。

無論你是使用還是在編寫JavaScript庫，新版瀏覽器對Selector API的支援必將給所有人的開發工作帶來直接的效能提升。換句話說，我們都將是受益者，萬歲！

Dojo之父Alex Russell在《Mastering Dojo》中為自己的工具箱所作的“廣告”：

Dojo基於相容未來標準的原則而構建，這些標準最終會在所有瀏覽器中實現，屆時開發人員將可以使用又快又簡單的本地方法。dojo.query方法就是一個非常好的例子。W3C Selectors API標準描述了一個通過CSS選擇符來查詢DOM樹的API，該Web API工作群組規定了一個編程用的方法，即querySelectorAll。querySelectorAll方法和dojo.query方法一樣，都返回一個節點數組。雖然Dojo的CSS查詢引擎速度很快，但通過讓查詢文法與CSS文法保持一致，有效地解決了始終要依賴該引擎的問題。事實上，在完全支援上述API的瀏覽器中，Dojo會使用querySelectorAll方法。相信dojo.query成為querySelectorsAll的封裝方法只是遲早的事——只不過通過封裝它還會為返回的節點數組添加一些甜美的文法糖（syntactic sugar）。最好的結果，就是上述API成為真正的標準，不再改變，開發人員也會因此全都享受到由C++實現的查詢引擎的快捷與便利，同時，更不會因向後相容問題而感到煩惱。對於Dojo使用者而言，選擇這個關注Web未來發展的工具箱，就等於已經享受到了上述好處。

事實上，Alex Russell確實是W3C Selector API的一個重要建議人。