QWrap選擇器的一個bug:tagName的大小寫
對于現(xiàn)代Web前端來說，Selector是必備之物。對于標準瀏覽器，可用querySelector，而對于IE8標準模式以下，需要一個Selector引擎。
因為本項目會在代碼里使用QWrap，所以雖然我寫的部分代碼并沒有用QWrap，但既然怎樣都需要一個Selector引擎，不如用QWrap。
結果發(fā)生一件悲劇的事情。
我使用html5-shim/shiv庫來讓IE正確解析新的HTML5標簽。但是QWrap引擎居然不能正確選擇出html5的元素。
嘗試人肉選擇，發(fā)現(xiàn)是可以的，那就是QWrap的Selector存在bug。
經(jīng)過艱苦卓絕的斗爭，最終發(fā)現(xiàn)問題出在這個函數(shù)的第2行：
- function(a) {
- sFun.push('el.tagName=="' + a.toUpperCase() + '"');
- return '';
- }).replace(/([\[(].*)|#([\w\-]+)|\.([\w\-]+)/g,//id縮略寫法//className縮略寫法
QWrap采用了代碼生成技術，即為selector拼裝出對應的函數(shù)。這是一項相當陷阱先進的技術。
不難看出這里會產(chǎn)生一個tag的匹配，對于匹配“nav”所生成的代碼應該是：el.tagName=="nav".toUpperCase() 。
通常瀏覽器對于所有HTML元素，其調(diào)用tagName返回的都是全大寫字母。
【號外】為什么是大寫?
Hax答：這是從HTML的祖先SGML那里繼承下來的習慣。對于早期寫SGML/HTML的人，要區(qū)分標簽和正文內(nèi)容的最簡單方法恐怕就是把標簽用大寫。
不過，據(jù)圈子里有名的那個紋身佬說，HTML用大寫是因為那時候技術落后，存儲太緊張，全大寫比較省存儲空間……(大意如此，詳情我記不清了，請八卦人士咨詢Winter)
【/號外】
然而不幸的是，html5-shim以及我所知差不多所有的類似庫，都會使用全小寫。這是因為現(xiàn)代Web標準的主流是采用全小寫。
【號外】為什么換小寫了涅?
Hax答：因為這樣比較不傷眼，也不傷手。
【/號外】
而IE雖然對于它所能識別的HTML元素都是大小寫不敏感的，但是對于通過createElement神經(jīng)刀產(chǎn)生的新元素，它其實將其視作類XML元素，也就是大小寫敏感的，所以其tagName屬性將返回最初設定的大小寫形式。
如何fix這個問題?
一個容易想到的方式是把html5-shim里的標簽列表改為大寫。不過這個方式并不管用。因為tagName返回的是最初設定的值，也就是，如果你寫...，返回的是SECTION，如果你寫...返回的就是SECtion(即start tag的大小寫)，如果你寫document.createElement('sEcTion')，返回的就是sEcTion。
顯然，QWrap Selector(或任何通用腳本庫)不應依賴網(wǎng)頁作者如何書寫。所以這個問題必須由QW來解決。
此外，庫也不應該假設tagName一定返回大寫。雖然規(guī)范規(guī)定對于HTML元素tagName應該始終返回大寫，但庫必須考慮兼容性(即這里所提到的IE的問題)。
此外，通用腳本庫也要有前瞻性，比如考慮Selector引擎用于選擇XML元素。當前各種純JS selector engine并非namespace-aware，所以本不能選擇XML元素。但HTML規(guī)范已經(jīng)允許直接在HTML里混合MathML、SVG。新的瀏覽器也都已經(jīng)支持了。
比如你可以試著在FireFox里看下述代碼：
- <body>
- <div id="test"><math>
- <mi>x</mi>
- <mo>=</mo>
- <mfrac>
- <mrow>
- <mo form="prefix">−</mo> <mi>b</mi>
- <mo>±</mo>
- <msqrt>
- <msup> <mi>b</mi> <mn>2</mn> </msup>
- <mo>−</mo>
- <mn>4</mn> <mo></mo> <mi>a</mi> <mo></mo> <mi>c</mi>
- </msqrt>
- </mrow>
- <mrow>
- <mn>2</mn> <mo></mo> <mi>a</mi>
- </mrow>
- </mfrac>
- </math></div>
- </body>
你可以看到$('test').firstChild.tagName返回的是“math”而不是“MATH”。而document.querySelector('#test math')也可以正確選擇到該元素。
但是QW Selector就不能選擇到math元素了。
【擴展】
假如你在這個文檔里插入document.createElement('math')會發(fā)生什么呢?
注意，你插入的不是一個MathML元素，那需要通過createElementNS，加上適當?shù)膎amespace(http://www.w3.org/1998/Math/MathML)才可以。你插入的其實是一個名字恰好為“math”的HTML元素，該元素的tagName返回的是全大寫的“MATH”。
此時，使用getElementsByTagName('math')或document.querySelectorAll('math')會返回這兩個元素。而getElementsByTagName('MATH')或document.querySelectorAll('MATH')只會返回那個正好叫做“math”的HTML元素，而不會返回真正的MathML的math元素。注：FF行為如此，而目前Chrome是兩者都返回的，這應該是WebKit的bug。
【/擴展】
盡管純JS Selector引擎主要的目的是向前兼容，但若能做到向后兼容就更好了。而QW Selector由于這個小小的大小寫問題，在兩方面都失敗了。
好在，修正它是很容易的。
sFun.push('el.tagName=="' + a.toUpperCase() + '"');
改為
sFun.push('el.tagName.toLowerCase()=="' + a.toLowerCase() + '"');
即可。
有人可能會問，為啥全換成toLowerCase()?
之前人家木有說過嗎，UPPERCASE什么的最討厭了!
說正經(jīng)的，用toLowerCase()是因為標準所規(guī)定的行為就是這樣的。盡管全換成toUpperCase()似乎也沒有什么不一樣的。
上述代碼的結果和目前Chrome的行為較為一致，即即使是非HTML namespace的元素，也按照大小寫不敏感的方式比較。如果要按照FF的行為，可以改為：
'isHTMLElement(el) ? tagName.toLowerCase() == "{a.toLowerCase()}" : tagName == "{a}"'
上述isHTMLElement檢測一個元素是否是HTML元素，邏輯請自行查標準確定。{a}這里用模板語法，這是為了讓大家看得更明白，我也省下打許多引號和加號的力氣。
原文：http://hax.iteye.com/blog/1126134
【編輯推薦】
