討論 指向目標元素
你經常希望使用event handler內部的目標object。通過DOM 0，使用handling功能內部特殊的this變數，可以指向目標的event object，來看如下的代碼：
在這裏，this指向ID為mylink的鏈結。我們可以使用它獲得這個鏈結的href屬性。
但是，如果你使用W3C事件監聽器，事件（event）的target作為event object的一部分存儲，在不同的流覽器中存儲在不同的property下面。IE將target存儲為srcElement，而其他的流覽器存儲為target。但是，這些property指向的元素不是事件監聽確定分配的事件。
事實上，不同層次的元素受事件的影響。來看如下的HTML。
如果一個click事件監聽被放在一個段落中，一個用戶點擊了這個click，這個段落的click 事件處理（event handler）就會執行，但是事件的目標將是超連結。有些流覽器（最明顯的就是Safari）甚至將鏈結內包含的文本節點isuan為目標節點。
我們可以編寫一個function返回事件的目標，而不論哪個property被執行，但是這並不能解決我們找尋我們原始應用事件監聽的元素。通常，最好的解決方法就是重複流覽器提供的事件目標，直到我們找到那個原始的元素為止。為了做到這點，我們可以按照元素標籤的名稱、class以及其他屬性進行檢索。
提煉事件目標的function可以是這樣的：
If-else可以跨流覽器找回事件目標，如果目標被流覽器報告為文本節點，while迴圈可以找到最上級的非文本節點。
如果我們想要返回被點擊的那個元素，我們可以調用getEventTarget:
因為我們知道，這這種情況下，事件處理功能只會附件到連接上（<a>標籤），我們可以重複事件目標，檢查節點名稱“a”。我們找到的第一個將是handler分配到的鏈結，這就確保了我們不是在鏈結內部查找一些元素（比如strong或者span）。
很明顯，查找target的方法並不是很理想，而且也不是100%的準確，除非你知道準確的HTML，最近，關於這個問題進行了很多研究，而且有很多解決方法都提供了在DOM 0處理器下與this相同的變數，而且在支援W3C的流覽器（不是IE）中，也有了一些解決的方法。
其中一個解決方法就是讓事件監聽功能成為IE目標object中的一個方法。然後，當調用這個方法的時候，this就會自然的指向那個被調用的方法。這就要求attachEventListener和detachEventListener同時進行修正：
在Peter Paul Koch的improved addEvent competition中對這些內容進行了詳細的說明。
Dean Edwards提出的另一個解決方法就是完全避開W3C使用DOM 0，具有可以單獨的增加或者去除的功能。
雖然這兩種方法都可能是非常不錯的方法，但是他們都沒有經過完整的測試，所以，我們將使用我們瞭解其優缺點的那種方法。另外，重複尋找一個事件的目標並不是不可靠的。
推薦給同仁
您想要瞭解更多的免費小竅門以便提升你的網站排名嗎？
請馬上聯繫我們網站管理員:
MSN: chenlinwu@cmmail.com
Email: info@rank-ad.com
