當(dāng)前位置：首頁 > 前端技术 > javascript >内容正文

javascript

dhtml_DHTML乌托邦：使用JavaScript和DOM的现代Web设计

發(fā)布時間：2023/12/8 javascript 66 豆豆

生活随笔收集整理的這篇文章主要介紹了 dhtml_DHTML乌托邦：使用JavaScript和DOM的现代Web设计小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

dhtml

動態(tài)HTML（簡稱DHTML）是一組Web開發(fā)技術(shù)的名稱，這些技術(shù)主要用于具有非平凡用戶輸入功能的Web頁面。 DHTML意味著處理HTML文檔的文檔對象模型，在樣式信息中擺弄CSS指令，并使用客戶端JavaScript腳本將所有內(nèi)容綁定在一起。

DHTML烏托邦：使用JavaScript和DOM的現(xiàn)代Web設(shè)計

該摘錄摘自SitePoint的新發(fā)行版DHTML Utopia：使用JavaScript和DOM的現(xiàn)代Web設(shè)計。該標(biāo)題包含300多頁的DHTML技術(shù)，這些技術(shù)可在不犧牲可用性或不遵守標(biāo)準(zhǔn)的情況下豐富用戶體驗。

作者，SitePoint自己的Stuart Langridge，利用了Web標(biāo)準(zhǔn)，并在構(gòu)建引人入勝的，可用的和交互式的DHTML應(yīng)用程序時，將代碼與標(biāo)記分開，從而優(yōu)雅地降級。

DHTML烏托邦：使用JavaScript和DOM進行現(xiàn)代Web設(shè)計探討了文檔對象模型，遠程腳本，Ajax，XML-RPC和xPath等技術(shù)，向您展示了如何為自己的Web項目創(chuàng)建應(yīng)用程序。建立自己的符合標(biāo)準(zhǔn)的分層導(dǎo)航菜單；創(chuàng)建動畫工具提示；使用正則表達式驗證表單數(shù)據(jù)并向用戶提供動態(tài)反饋；構(gòu)造一個AJAX注冊表單，該表單可以讓用戶知道他們選擇的用戶名是否已被使用，而無需自己提交表單。

本書提供了無數(shù)的DHTML應(yīng)用程序，這些應(yīng)用程序?qū)⒏纳颇木W(wǎng)站在支持標(biāo)準(zhǔn)的瀏覽器中的交互性，并在不支持標(biāo)準(zhǔn)的瀏覽器中優(yōu)雅地降級。

前四章應(yīng)該讓您了解操作。要查找有關(guān)該書的更多信息，請訪問該書的頁面，或查看整個出版物的內(nèi)容。與往常一樣，如果愿意，您可以將本摘錄下載為PDF 。現(xiàn)在，轉(zhuǎn)到第1章。

第1章DHTML技術(shù)

在此介紹性部分中，我將簡要概述您需要了解的一些事項：構(gòu)成DHTML網(wǎng)站的構(gòu)建基塊。如果需要刷新內(nèi)存，您會發(fā)現(xiàn)它很有用。如果您已經(jīng)知道所有這些詳細信息，則可能還是要翻閱本章。您甚至可能會對其中的一些感到驚訝。在接下來的頁面中，我們將了解DHTML實際上是內(nèi)容的正確HTML，設(shè)計的級聯(lián)樣式表和交互性JavaScript的組合。將這些技術(shù)混合在一起可以燉得很清淡或自助餐很豐盛。這一切都是烹飪藝術(shù)，所以讓我們開始為那些鍋碗瓢盆嘎嘎作響吧！

HTML起點

網(wǎng)站是用HTML編寫的。如果您正在閱讀這本書，您幾乎可以肯定會知道HTML是什么，并且至少會對HTML有一定的經(jīng)驗。對于成功的DHTML增強網(wǎng)站，至關(guān)重要的是您HTML有兩點：有效和語義。這些需求可能需要改變您以前編寫HTML的經(jīng)驗。與讓您的首選工具為您編寫HTML相比，它們可能還需要其他方法。

升級到有效HTML

HTML建議中列出了一組特定的規(guī)則，規(guī)定了應(yīng)如何編寫HTML。符合這些規(guī)則HTML被稱為“有效”。您HTML必須有效，以便可以用作構(gòu)建DHTML增強功能的基礎(chǔ)。雖然規(guī)則集非常復(fù)雜，但是您可以通過遵循一些簡單的準(zhǔn)則來確保HTML有效。

正確嵌套標(biāo)簽

不要讓標(biāo)簽彼此“交叉”。例如，沒有看起來如下所示HTML代碼：

Here is some <strong>bold and <em>italic</strong> text</em>.

在這里， <strong>和<em>標(biāo)記彼此交叉；它們被錯誤地嵌套。嵌套對于正確使用DHTML極為重要。在本書的后續(xù)章節(jié)中，我們將研究DOM樹，并且不正確的嵌套導(dǎo)致問題的原因?qū)⒆兊酶忧宄?現(xiàn)在，只需記住，如果您跨標(biāo)簽，每個瀏覽器將根據(jù)不同的規(guī)則（而不是根據(jù)標(biāo)準(zhǔn)）以不同的方式解釋您的代碼。除非您正確執(zhí)行此操作，否則您希望能夠跨瀏覽器控制頁面外觀和功能的任何希望都會消失。

關(guān)閉容器標(biāo)簽

包含其他項目的諸如<strong>或<p>標(biāo)簽應(yīng)始終使用</strong>或</p>或適當(dāng)?shù)慕Y(jié)束標(biāo)簽關(guān)閉。重要的是要知道哪些標(biāo)簽包含東西（例如文本或其他標(biāo)簽），并確保將其關(guān)閉。例如， <p>并不意味著“在這里放入一個段落中斷”，而是“一個段落在這里開始”，并且應(yīng)該與</p>配對，“該段落在這里結(jié)束”。（知道容器標(biāo)記用途的人會意識到HTML 4.01實際上并不需要關(guān)閉所有容器標(biāo)記（盡管XHTML仍然要求關(guān)閉）。但是，關(guān)閉容器標(biāo)記永遠不會無效，盡管有時這樣做是無效的。僅關(guān)閉所有內(nèi)容比記住允許您保持打開狀態(tài)的標(biāo)記要容易得多。）同樣的邏輯也適用于<li>標(biāo)記。

一律使用文件類型

文檔類型（或DOCTYPE）描述了已使用HTML的方言。有幾種不同的選擇。在本書中，我們將使用稱為HTML 4.01 Strict的方言。（如果您正在考慮“但是我想使用XHTML！”，那么我敢打賭，您已經(jīng)對DOCTYPE有足夠的了解，可以正確使用它們。）您的DOCTYPE應(yīng)該顯示在每個HTML頁面的最頂部，看起來應(yīng)該像這樣：

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">

這些信息可以在一行中鍵入，或者與后一個換行符EN"別擔(dān)心，就目前而言，這意味著什么：。只是一定要放置在每個頁面頂部的文章解決您的發(fā)布于A List Apart上的“ 具有正確DOCTYPE！”的站點列出了您可能要使用的所有DOCTYPE，以及為什么需要使用它們的全部原因。我一直訪問該文章，以剪切并粘貼我需要的DOCTYPE！！

驗證您的頁面

免費學(xué)習(xí)PHP！

全面介紹PHP和MySQL，從而實現(xiàn)服務(wù)器端編程的飛躍。

原價$ 11.95 您的完全免費

最重要的頁面創(chuàng)建步驟是檢查HTML是否有效。您可以下載許多工具并在自己的計算機上運行這些工具來測試代碼的有效性-一些HTML編輯器甚至內(nèi)置了此類工具-或者您可以使用許多在線驗證器之一，其中最常見的是W3C自己的驗證器。驗證程序?qū)⒏嬖V您如何調(diào)整HTML以使其與DHTML技術(shù)兼容。構(gòu)成有效HTML的最終參考是HTML建議。它是復(fù)雜且詳細的，但是如果您對應(yīng)如何編寫HTML或是否確實存在標(biāo)簽有任何疑問，則可以在此處找到答案。如上所述，瀏覽器依賴于描述如何解釋經(jīng)過驗證HTML的標(biāo)準(zhǔn)。但是，沒有標(biāo)準(zhǔn)來描述如何解釋無效HTML。每個瀏覽器制造商都建立了自己的規(guī)則來彌補這一空白。試圖理解所有這些規(guī)則將是困難而費力的，并且您會花費更多的時間。堅持使用有效HTML意味著您發(fā)現(xiàn)的任何問題都被認(rèn)為是該瀏覽器中的錯誤-您可能可以解決的錯誤。因此，使用有效HTML可讓您有更多時間與家人在一起，玩斯諾克臺球等。如果您問我，這是這樣做的一個很好的理由。

加強語義HTML

除了其有效性之外，您HTML還應(yīng)該是語義性的，而不是表示性的。這意味著您應(yīng)該使用HTML標(biāo)記來描述文檔中元素的性質(zhì)，而不是該元素的外觀。因此，如果您的意思是“在此處輸入空白行”，請不要使用<p>標(biāo)記。用它來表示“一個段落從這里開始”（并在該段落的末尾放置一個</p> ）。不要使用<blockquote>來表示“縮進下一段文本”。用它來表示“此塊是引號”。如果以這種方式標(biāo)記HTML，則會發(fā)現(xiàn)將DHTML技術(shù)應(yīng)用到此行中會更加容易。這種方法稱為語義標(biāo)記 -一種奇特的說法，“使用標(biāo)簽描述含義”。

讓我們看一些示例片段。首先，假設(shè)您的網(wǎng)站有指向不同部分的鏈接列表。該列表應(yīng)根據(jù)其內(nèi)容進行標(biāo)記：一個列表。不要將其設(shè)置為由<br>標(biāo)記分隔的<a>標(biāo)記集；這是一個列表，因此應(yīng)使用<ul>和<li>標(biāo)簽對其進行標(biāo)記。它可能看起來像這樣：

<ul>
<li><a href="index.html">Home</a></li>
<li><a href="about.html">About this Website</a></li>
<li><a href="email.html">Contact details</a></li>
</ul>

您會發(fā)現(xiàn)自己經(jīng)常使用<ul>標(biāo)記。網(wǎng)站中的許多項目實際上都是列表：面包屑跟蹤是鏈接列表，菜單結(jié)構(gòu)是鏈接列表列表，照片庫是圖像列表。

同樣，如果您的列表包含與注釋相關(guān)聯(lián)的項目，則可能應(yīng)將其標(biāo)記為定義列表：

<dl>
<dt><a href="index.html">Home</a></dt>
<dd>Back to the home page</dd>
<dt><a href="about.html">About this Website</a></dt>
<dd>Why this site exists, how it was set up, and who did it
</dd>
<dt><a href="email.html">Contact details</a></dt>
<dd>Getting in contact with the Webmaster: email addresses
and phone numbers</dd>
</dl>

請記住：頁面的外觀并不真正相關(guān)。重要的是，頁面中的信息以描述其內(nèi)容的方式進行標(biāo)記。 HTML中有很多標(biāo)簽；不要將它們視為在頁面上布置信息的方法，而是將其定義為信息的含義。

如果您不使用HTML來控制頁面的顯示，如何使它們看起來像您希望的那樣？這就是級聯(lián)樣式表的來源。

添加CSS

級聯(lián)樣式表（CSS）是一種允許您描述HTML表示形式的技術(shù)。本質(zhì)上，它允許您聲明頁面上每個元素的外觀。元素是一段HTML，代表一件事：一個段落，一個標(biāo)題，一個圖像，一個列表。元素通常對應(yīng)于特定標(biāo)簽及其內(nèi)容。使用CSS樣式時，DHTML頁面可以獨立處理頁面的外觀和內(nèi)容。這是一個方便而干凈的分隔。如果您想看起來不錯，就需要學(xué)習(xí)如何打扮，并定期去健身房！

一個簡單CSS示例

假設(shè)您希望主頁標(biāo)題（ <h1>標(biāo)記）以大，紅色，居中的文本顯示。您應(yīng)該在樣式表中指定以下內(nèi)容：

h1 {
font-size: 300%;
color: #FF0000;
text-align: center;
}

有關(guān)CSS入門教程的一些鏈接，請參閱本章末尾的“更多閱讀”部分，如果以上幾行對您沒有太大意義，則應(yīng)該有所幫助。

在應(yīng)用這些樣式之前和之后，這是一個簡單HTML頁面：

圖1.1。 那個HTML的風(fēng)格！

這里的關(guān)鍵點是從HTML中刪除表示方面，并將其放入樣式表中。例如，如果您通過在HTML中放置<font>標(biāo)記來使頁面標(biāo)題變大，則需要將這些標(biāo)記粘貼到使用標(biāo)題的每個頁面中。通過使HTML語義化并將頁面的表示形式移動到CSS中，您可以通過一個樣式表來控制整個網(wǎng)站標(biāo)題的外觀。這使您作為網(wǎng)站開發(fā)人員的工作更加輕松。

當(dāng)然，這并不那么容易。盡管CSS的完整定義使您可以做一些相當(dāng)令人驚奇的事情，并在很大程度上控制頁面的顯示，但是并不是每個瀏覽器都支持CSS所提供的所有功能。

為了了解瀏覽器對CSS支持的差異，您需要知道CSS可以做什么。瀏覽器不兼容有兩種：給定瀏覽器不實現(xiàn)的功能和不正確實現(xiàn)的功能。有時，瀏覽器也會添加自己的“特殊功能”，但是我們不會擔(dān)心本書中的那些功能。

缺少的實現(xiàn)相對容易處理：如果您希望CSS在無法實現(xiàn)這些規(guī)則的瀏覽器中運行，請不要依賴此類規(guī)則。這可能會很痛苦，尤其是因為世界上最常用的瀏覽器Windows版Internet Explorer在CSS支持方面存在一些嚴(yán)重漏洞；但是，這種“解決方案”通常是必要的折衷方案。了解可以使用和不使用哪些規(guī)則是CSS專家體系的步驟之一。

執(zhí)行不力的標(biāo)準(zhǔn)是一個更大的問題。在這種情況下，瀏覽器會出錯。 CSS專家的另一個步驟是確切地了解每個瀏覽器的錯誤之處，以及如何解決這些錯誤。但是，您不需要這些知識就可以開始學(xué)習(xí)：隨著學(xué)習(xí)的進行，您會逐漸掌握它。通常使用CSS hacks來解決不同瀏覽器中CSS bug。這些黑客利用瀏覽器CSS解析器中的錯誤為它提供了特定的樣式表指令，這些指令可解決其標(biāo)準(zhǔn)實施不力的問題。針對網(wǎng)絡(luò)中各個地方的每個瀏覽器，記錄了各種各樣CSS hack。有關(guān)更多信息，請參見“進一步閱讀”部分。

學(xué)會理解和適應(yīng)各種瀏覽器中各種CSS處理是有效使用CSS所需的工作的一部分。盡管可能需要大量工作，但許多CSS錯誤只有通過復(fù)雜使用該技術(shù)才能變得明顯。大多數(shù)CSS可以在各種平臺和瀏覽器上完美處理，而無需黑客或復(fù)雜的測試。

盡管CSS功能強大，但并不能給我們真正的靈活性。 CSS的功能一直在增加，并且越來越多的“交互式”功能不斷添加到CSS規(guī)范中。但是，它并非旨在構(gòu)建真正的交互式網(wǎng)站。為此，我們需要DHTML的最后一個構(gòu)建塊：JavaScript。

添加JavaScript

JavaScript是一種簡單但功能強大的編程語言。它用于向您的網(wǎng)站添加動態(tài)行為-DHTML中的D。 HTML定義了頁面的結(jié)構(gòu)，CSS定義了它的外觀，但是動作，與頁面交互時發(fā)生的事情（單擊按鈕，拖動圖像或移動鼠標(biāo)）在JavaScript中定義。 JavaScript與下一章所述的文檔對象模型一起使用，可將動作附加到不同的事件（鼠標(biāo)懸停，拖動和單擊）。我們不會在這里詳細描述所有復(fù)雜JavaScript語法-如果需要，“深入閱讀”部分提供了一些JavaScript教程的鏈接。

一個簡單JavaScript示例

這是一段簡單JavaScript，可在用戶跳出字段時將文本字段的值轉(zhuǎn)換為大寫。首先，讓我們看一下舊的，糟糕的方法：

范例1.1 oldlisteners.html （節(jié)選）

在本書中，我們將推薦一種更現(xiàn)代的技術(shù)。首先，HTML：

范例1.2 newlisteners.html （節(jié)選）

其次，JavaScript，通常位于頁面的<head>部分：

示例1.3 newlisteners.html （節(jié)選）

第一個功能完成轉(zhuǎn)換文本的工作。第二個功能確保第一個功能連接到正確HTML標(biāo)簽。頁面完全加載后，最后一行執(zhí)行此連接。盡管這意味著需要更多代碼，但請注意如何使HTML內(nèi)容保持簡潔。在以后的章節(jié)中，我們將大量探討這種方法。現(xiàn)在不用擔(dān)心太多的機制了-有足夠的時間了！

獲取一些工具！

良好JavaScript開發(fā)環(huán)境使JavaScript的使用比以前容易得多。在Internet Explorer（IE）中測試頁面可能會有一些不足之處。如果您的頁面生成JavaScript錯誤（在構(gòu)建過程中會一直發(fā)生！），則IE在診斷它們的位置或位置方面可能不會很有幫助。用于JavaScript調(diào)試的最有用但最簡單的工具是Mozilla或Mozilla Firefox中JavaScript控制臺。該控制臺將清楚顯示頁面上發(fā)生JavaScript錯誤的位置以及該錯誤是什么。在構(gòu)建JavaScript腳本時，這是一個寶貴的工具。 Mozilla Firefox幾乎可以在所有平臺上運行，下載量并不大。與Internet Explorer相比，它還為CSS提供了更好的支持，并且應(yīng)該成為開發(fā)工具包的一部分。除此之外，Mozilla中還有一個JavaScript調(diào)試器，名為Venkman。如果您是那種使用其他語言處理大型項目并習(xí)慣于調(diào)試器的編碼器，那么Venkman會很有用，但是請注意，這需要一些設(shè)置。但是，實際上，當(dāng)您使用DHTML增強網(wǎng)站時，您不需要像調(diào)試器那樣復(fù)雜的東西。 JavaScript控制臺以及明智地使用警報語句來識別正在發(fā)生的事情，將幫助您應(yīng)對幾乎每種情況。

另一個絕對有用的工具是一個好的代碼編輯器，可在其中編寫您的網(wǎng)站。 JavaScript的語法高亮是一個非常方便的功能。它使您在編寫代碼時更易于閱讀，并在省略括號或引號時Swift提醒您。編輯器是一個非常個人化的工具，在這方面，您可能需要先親吻一些青蛙，然后才能找到您的王子，但是好的編輯器會認(rèn)真地加快并簡化您的編碼工作。如果您還沒有首選程序，則可以免費使用許多功能強大的可自定義編輯器。但是，如果您當(dāng)前正在使用Windows記事本編寫代碼，請查看還有哪些可用的功能來查看是否有其他產(chǎn)品提供了您更喜歡的環(huán)境。如前所述，您需要語法高亮顯示；綁定頁面外部驗證的一種方法也很有用。 Textpad和Crimson Editor是基于Windows的編輯器，如果您在Windows平臺上進行開發(fā)，則涵蓋了基礎(chǔ)知識。 Mac用戶傾向于使用BBEdit ； Linux用戶可以使用gedit或Kate或vim進行基礎(chǔ)操作，并且始終有Emacs。

JavaScript是運行DHTML的引擎。 DHTML專注于處理HTML和CSS，以使頁面能夠執(zhí)行用戶想要的操作，而JavaScript則可以實現(xiàn)這種操作。在本書的其余部分，我們將越來越詳細地探討這種操作。

進一步閱讀

如果您想了解有關(guān)CSS本身的更多信息，請嘗試這些鏈接。

SitePoint對CSS世界的簡單介紹是一個很好的起點。

無論您是學(xué)習(xí)還是簡單地學(xué)習(xí)CSS知識， W3SchoolsCSS教程都會對您有所幫助。

CSS Zen Garden很好地展示了層疊樣式表的強大功能。它有一個真正的哇！

如果您需要向特定的瀏覽器隱藏某些CSS指令（或提供某些指令），則此CSS hack的詳細列表向您顯示哪些瀏覽器將受到給定的hack的影響。

該站點演示了各種瀏覽器中CSS問題，并說明了如何解決這些問題。

CSS-Discuss郵件列表 “專門討論CSS及其在現(xiàn)實世界中的使用方式；換句話說，是實際用途和應(yīng)用程序”。關(guān)聯(lián)的Wiki是有用技巧和竅門的存儲庫。

如果您需要更明確的內(nèi)容，SitePoint的書《 HTML烏托邦：使用CSS不用表進行設(shè)計》是CSS初學(xué)者的完整指南和參考。如果您喜歡邊做邊學(xué)，那么CSS選集：101技巧，竅門和技巧是一個完美的選擇。

Web上的許多教程都涉及JavaScript。有些瀏覽了DHTML和DOM，而另一些則沒有。您應(yīng)該嘗試找到前者。

本教程為整個非程序員介紹了JavaScript的基礎(chǔ)知識。本文介紹的某些技術(shù)并不像本書介紹的替代技術(shù)那樣現(xiàn)代，但是您會對該語言本身有很好的了解。

Peter-Paul Koch的JS技術(shù)和腳本列表涵蓋了該領(lǐng)域的大量知識。

摘要

在本章中，我們概述了DHTML的最基本構(gòu)建塊：真正HTML，如何使用CSS在文檔中排列和顯示它，以及如何使用JavaScript添加交互性。在本書的其余部分中，我們將研究可用于使網(wǎng)站動態(tài)化的基本技術(shù)，然后繼續(xù)討論涵蓋特定領(lǐng)域的某些高級腳本技術(shù)。繼續(xù)演出！

第2章文檔對象模型

有一天，有人進來，在電傳打字機之一伸出來的紙上，以巨大的隔離顯示了這個不祥的短語：

值：

會引起dom！

……這句話本身真是太令人驚訝了！完全沒有意義，但看起來像什么……警告？什么是“ dom”？
— 丹尼斯·里奇（ Dennis M. Richie）

網(wǎng)頁是一個文檔。要查看該文檔，可以將其顯示在瀏覽器窗口中，也可以查看HTML源代碼。兩種情況下都是相同的文檔。萬維網(wǎng)聯(lián)盟的文檔對象模型（DOM）提供了另一種查看同一文檔的方法。它將文檔內(nèi)容描述為JavaScript程序可以看到的一組對象。自然，這對于發(fā)生大量腳本的DHTML頁面非常有用。（上面的引用純屬巧合–是從網(wǎng)絡(luò)出現(xiàn)之前開始的！）

根據(jù)萬維網(wǎng)聯(lián)盟的說法，“文檔對象模型是一種與平臺和語言無關(guān)的界面，它將允許程序和腳本動態(tài)訪問和更新文檔的內(nèi)容，結(jié)構(gòu)和樣式。可以對文檔進行進一步處理，并且該處理的結(jié)果可以并入所顯示的頁面。” 這句話基本上說DOM不僅是新穎的，而且對做事很有用。在接下來的頁面中，我們將簡要介紹DOM的歷史，然后更深入地研究它的含義和使用方法。我們將以一些示例腳本結(jié)束，這些腳本演示了DHTML的這一關(guān)鍵方面的強大功能。

DOM的起源

在Netscape Navigator 2中，Netscape Communications引入了JavaScript（簡稱為LiveScript），它使Web開發(fā)人員可以腳本訪問其網(wǎng)頁中的元素-首先訪問表單，然后訪問圖像，鏈接和其他功能。為了與Netscape保持同步，Microsoft在Internet Explorer 3中實現(xiàn)了JavaScript（盡管他們將其稱為JScript）。

在第4版中，這兩種瀏覽器在各自的功能集和對頁面內(nèi)容的訪問方面都大相徑庭。每個瀏覽器制造商都實現(xiàn)了自己的專有方法來提供對層的腳本訪問。希望在兩種瀏覽器中都可以使用的腳本需要包含每種方法的代碼。命運不佳的“瀏覽器之戰(zhàn)”全都是這些專有的Web擴展，因為每個制造商都在努力通過吸引新功能來吸引更多開發(fā)人員使用其平臺。盡管Microsoft復(fù)制并支持Netscape所做的大多數(shù)早期創(chuàng)新，但幾乎沒有考慮跨瀏覽器的兼容性。

在進行所有這些操作的同時，W3C制定了文檔對象模型級別1的規(guī)范，概述了使用腳本訪問XML文檔各個部分的通用和標(biāo)準(zhǔn)方法。由于HTML可以被視為XML的方言，因此DOM Level 1規(guī)范也適用于HTML。

兩家主要的瀏覽器制造商都實施了DOM級別1規(guī)范：在Internet Explorer 5和Netscape 6中。由于新標(biāo)準(zhǔn)是DOM級別1，所以那些舊的且現(xiàn)在不推薦使用的方法稱為DOM級別0。。）盡管沒有正式的DOM Level 0標(biāo)準(zhǔn)。

什么是DOM？

因此，您知道DOM 曾經(jīng)是什么。現(xiàn)在讓我們討論它是什么。

本質(zhì)上，DOM通過將頁面中的元素映射到節(jié)點樹來提供對HTML頁面結(jié)構(gòu)的訪問。每個元素成為一個元素節(jié)點，文本的每一位成為一個文本節(jié)點。以以下HTML代碼段為例：

<body>
<p> ?
This is a paragraph, containing ?
<a href="#"> ?
a link ?
</a> ?
in the middle. ?
</p> ?
<ul> ?
<li> ?
This item has ?
<em> ?
some emphasized text ?
</em> ?
in it. ?
</li> ?
<li> ?
This is another list item. ?
</li> ?
</ul> ?
</body>

我添加了許多額外的縮進，以便您可以將此代碼段與匹配的DOM樹進行比較。在現(xiàn)實生活中不要這樣做–在這種情況下，我只是想讓事情變得更清楚。匹配的DOM樹如圖2.1所示。

正如你所看到的， a元素，它位于內(nèi)側(cè)p元素在HTML，成為一個子節(jié)點，或者只是孩子，的p DOM樹節(jié)點。（對稱地， p節(jié)點是父 a節(jié)點。這兩個li節(jié)點，相同父的兒童，被稱為兄弟節(jié)點或只是兄弟姐妹。）

請注意，HTML標(biāo)記中每個標(biāo)簽的嵌套級別與到達DOM樹中相同項目所需的行數(shù)相匹配。例如， <a>標(biāo)簽在其他標(biāo)簽（ <p>和<body>標(biāo)簽）內(nèi)嵌套了兩次，因此樹中的a節(jié)點位于頂部兩行。

圖2.1。 DOM樹的示例。

有效HTML的重要性

從最后一個示例中，我們可以更清楚地看到為什么有效HTML（包括正確嵌套的元素）如此重要的原因。如果元素嵌套不正確，則會出現(xiàn)問題。采取以下行：

<strong>These <em>elements are</strong> badly nested</em>.

由此錯誤嵌套的代碼產(chǎn)生的DOM樹根本不會是一棵樹：為了表示此HTML請求的無效元素布局，需要將其畸形。每種瀏覽器都以不同的方式修復(fù)格式錯誤的內(nèi)容，這可能會產(chǎn)生諸如作為其自身父節(jié)點的元素之類的恐怖。保持HTML有效可以避免所有這些問題。

行走的DOM樹

節(jié)點樹在計算中的應(yīng)用非常廣泛，因為它們具有非常有用的屬性：輕松進行“遍歷樹”（即按順序遍歷樹中的每個節(jié)點）很容易。碼。漫步一棵樹很容易，因為任何元素節(jié)點都可以視為其自己的小樹的頂部。因此，要遍歷一棵樹，可以使用一系列步驟，例如：

對我們正在尋找的節(jié)點做一些事情

這個節(jié)點有孩子嗎？如果是這樣的話：

對于每個子節(jié)點，請轉(zhuǎn)到步驟1

此過程稱為遞歸，并且定義為對調(diào)用自身的函數(shù)的使用。每個孩子都是與父母同類型的事物，因此可以用相同的方式處理。我們自己對遞歸的處理不多，但我們在很大程度上依賴瀏覽器在頁面樹中的遞歸。當(dāng)需要處理事件時，它特別有用，我們將在第3章“處理DOM事件”中看到。

尋找樹頂

為了遍歷DOM樹，您需要引用其頂部的節(jié)點：根節(jié)點。該“引用”將是一個指向根節(jié)點的變量。根節(jié)點對于JavaScript應(yīng)該可以作為document.documentElement使用。并不是所有的瀏覽器都支持這種方法，但是幸運的是，這并不重要，因為您幾乎不需要從根開始遍歷整個文檔的DOM樹。相反，采用的方法是使用getElementsBy Whatever方法之一直接獲取樹的特定部分。這些方法從window.document對象（或簡稱document）開始。

從樹中獲取元素

有兩種主要方法可用于獲取特定元素或元素集。在DHTML編程中一直使用的第一種方法是getElementById 。第二個是getElementsByTagName 。另一個方法getElementsByName很少使用，因此我們現(xiàn)在僅看前兩個方法。

getElementById

在HTML中，任何元素都可以具有唯一的ID。必須使用HTML id屬性指定ID：

<div id="codesection">
<p id="codepara"> ?
</p> ?
<ul> ?
<li><a href="http://www.sitepoint.com/" id="splink" ?
>SitePoint</a></li> ?
<li><a href="http://www.yahoo.com/" id="yalink" ?
>Yahoo!</a></li> ?
</ul> ?
</div>

該代碼段中的每個非列表元素都有一個ID。您應(yīng)該能夠發(fā)現(xiàn)其中的四個。 ID在您的文檔中必須是唯一的–每個元素必須具有不同的ID（或根本沒有ID）–因此您可以知道特定的ID僅標(biāo)識給定的元素。要在JavaScript代碼中獲得對該元素的引用，請使用document.getElementById( elementId ) ：

var sitepoint_link = document.getElementById('splink')

現(xiàn)在，變量sitepoint_link包含對上述HTML代碼段中第一個<a>標(biāo)記的引用。稍后我們將看到您可以使用該元素引用做什么。此HTML代碼段的DOM樹如圖2.2所示。

圖2.2。 代碼段的DOM樹。

getElementsByTagName

document.getElementsByTagName方法用于檢索特定類型的所有元素。該方法返回一個包含所有匹配元素的數(shù)組（從技術(shù)上講，它返回一個節(jié)點集合，但這就像一個數(shù)組一樣工作）：

var all_links = document.getElementsByTagName('a');
var sitepoint_link = all_links[0];

all_links變量包含一個數(shù)組，該數(shù)組包含兩個元素：對SitePoint鏈接的引用和對Yahoo!的引用。鏈接。元素以在HTML中找到的順序返回，因此all_links[0]是SitePoint鏈接，而all_links[1]是Yahoo!。鏈接。

請注意，即使僅找到一個匹配的元素， document.getElementsByTagName始終返回一個數(shù)組。假設(shè)我們使用以下方法：

var body_list = document.getElementsByTagName('body');

在這種情況下，要獲得對唯一body元素的引用，我們將需要使用以下內(nèi)容：

var body = body_list[0];

如果body_list.length （數(shù)組的大小）不是1，我們將感到非常驚訝，因為應(yīng)該只有一個<body>標(biāo)簽！我們還可以通過將前兩行替換為以下內(nèi)容來稍微縮短此過程：

var body = document.getElementsByTagName('body')[0];

JavaScript使您可以像這樣將表達式折疊在一起。它可以使您的代碼更加緊湊，并避免聲明很多實際上沒有用到的變量。

還有另一個有用的功能。 getElementsByTagName完全在任何節(jié)點上定義，而不僅僅是文檔。因此，要查找文檔正文中的所有<a>標(biāo)記，我們可以使用如下方法：

var links_in_body = body.getElementsByTagName('a');

請注意，“ Element”在此方法的名稱中為復(fù)數(shù)形式，但對于getElementById為單數(shù)形式。提醒您，前者返回元素數(shù)組，而后者僅返回單個元素。

從父母走到孩子

每個節(jié)點都有一個父節(jié)點（根元素除外），并且可能有多個子節(jié)點。您可以從節(jié)點的parentNode屬性獲得對節(jié)點的父節(jié)點的引用。在節(jié)點的childNodes屬性中可以找到節(jié)點的子級，該屬性是一個數(shù)組。如果節(jié)點沒有子節(jié)點，則childNodes數(shù)組可能不包含任何內(nèi)容（此類節(jié)點稱為葉節(jié)點）。

假設(shè)變量節(jié)點指向DOM樹的ul元素。我們可以這樣獲得節(jié)點的父節(jié)點（ div元素）：

parent = node.parentNode;

我們可以通過查看childNodes數(shù)組的length屬性來檢查無序列表是否有任何列表項（子項）：

if (node.childNodes.length == 0) {
alert('no list items found!'); ?
}

如果有子代，則其編號從零開始。我們可以在示例HTML（ li元素）中獲得第二個孩子，如下所示：

list_item = node.childNodes[1];

對于第一個孩子的特殊情況，位于：

list_item = node.childNodes[0];

我們還可以使用以下縮寫：

child = node.firstChild;

同樣，最后一個孩子（在本例中為第二個li ）具有自己的特殊屬性：

child = node.lastChild;

在本書的其余部分中，我們將常規(guī)使用所有這些屬性。

與Elements怎么辦

現(xiàn)在，您知道如何獲取對元素的引用– HTML頁面中的節(jié)點。 DHTML的核心–動態(tài)的D –在于我們更改，刪除和添加新元素的能力。在本章的其余部分中，我們將使用下面的代碼片段，我們先前已經(jīng)看到它們：

更改元素屬性

元素的每個屬性以及可以應(yīng)用到該元素的每種CSS樣式都可以通過JavaScript進行設(shè)置。也可以設(shè)置和讀取腳本中可以應(yīng)用于HTML元素的屬性（例如<a>標(biāo)記的href屬性），如下所示：

// using our sitepoint_link variable from above
sitepoint_link.href = "http://www.google.com/";

腳本運行后，單擊該鏈接，您將被帶到Google而不是SitePoint。新HTML內(nèi)容如瀏覽器所想（HTML文件本身未更改）一樣，如下所示：

<div id="codesection">
<p id="codepara"> ?
</p> ?
<ul> ?
<li><a href= "http://www.google.com/" id="splink" ?
>SitePoint</a></li> ?
<li><a href="http://www.yahoo.com/" id="yalink" ?
>Yahoo!</a></li> ?
</ul> ?
</div>

Each element has a different set of attributes that can be changed: a elements have the href attribute, <img> elements have the src attribute, and so on. In general, an attribute that can be applied to a tag in your HTML is also gettable and settable as a property on a node from JavaScript. So, if our code contains a reference to an img element, we can change the image that's displayed by altering the img_element.src property. (One notable divergence from this rule is that an element's class attribute in HTML is available in JavaScript as node.className , not node.class . This is because "class" is a JavaScript reserved word.)

The two most useful references that document elements and their supported attributes are those provided by the two major browser makers: the Microsoft DOM reference , and the Mozilla Foundation's DOM reference .

Importantly, though, when we altered our link's href above, all we changed was the destination for the link. The text of the link, which read "SitePoint" before, has not changed; if we need to alter that, we have to do so separately. Changing the text in a page is slightly more complex than changing an attribute; to alter text, you need to understand the concept of text nodes.

Changing Text Nodes

In Figure 2.1 above, you can see how the HTML in a document can be represented as a DOM tree. One of the important things the figure illustrates is that the text inside an element is not part of that element. In fact, the text is in a different node: a child of the element node. If you have a reference to that text node, you can change the text therein using the node's nodeValue property:

myTextNode.nodeValue = "Some text to go in the text node";

How can we get a reference to that text node? We need to walk the DOM tree – after all, we have to know where the text node is before we can alter it. If we consider the sitepoint_link node above, we can see that its childNodes array should contain one node: a text node with a nodeValue of "SitePoint" . We can change the value of that text node as follows:

sitepoint_link.childNodes[0].nodeValue = 'Google';

Now, the text displayed on-screen for that link will read Google, which matches the link destination that we changed earlier. We can shorten the code slightly to the following:

sitepoint_link.firstChild.nodeValue = 'Google';

You may recall that a node's firstChild property, and childNodes[0] , both refer to the same node; in this case, you can substitute childNodes[0] with success. After this change, the browser will see the following document code:

<div id="codesection">
<p id="codepara"> ?
</p> ?
<ul> ?
<li><a href="http://www.google.com/" id="splink" ?
>Google</a></li> ?
<li><a href="http://www.yahoo.com/" id="yalink" ?
>Yahoo!</a></li> ?
</ul> ?
</div>

Changing Style Properties

As we have seen, the attributes that are set on an HTML tag are available as properties of the corresponding DOM node. CSS style properties can also be applied to that node through the DOM, using the node's style property. Each CSS property is a property of that style property, with its name slightly transformed: a CSS property in words-and-dashes style becomes a property of style with dashes removed and all words but the first taking an initial capital letter. This is called InterCaps format . 這是一個例子。 A CSS property that was named:

some-css-property

would appear to a script as the following JavaScript property:

someCssProperty

So, to set the CSS property font-family for our sitepoint_link element node, we'd use the following code:

sitepoint_link.style.fontFamily = 'sans-serif';

CSS values in JavaScript are almost always set as strings; some values, such as font-size, are strings because they must contain a dimension, such as "px" or "%". (Internet Explorer will let you get away without using a dimension, as it assumes that a dimensionless number is actually a pixel measurement. However, do not try to take advantage of this assumption; it will break your code in other browsers, and it's in violation of the specification.) Only entirely numeric properties, such as z-index (which is set as node .style.zIndex , as per the above rule) may be set as a number:

sitepoint_link.style.zIndex = 2;

Many designers alter style properties to make an element appear or disappear. In CSS, the display property is used for this: if it's set to none , the element doesn't display in the browser. So, to hide an element from display, we can set its display property to none :

sitepoint_link.style.display = 'none';

To show it again, we give it another valid value:

sitepoint_link.style.display = 'inline';

For a complete reference to the available CSS style properties and what each does, see SitePoint's HTML Utopia: Designing Without Tables Using CSS .

Bigger DOM Tree Changes

The next level of DOM manipulation, above and beyond changing the properties of elements that are already there, is to add and remove elements dynamically. Being able to change the display properties of existing elements, and to read and alter the attributes of those elements, puts a lot of power at your disposal, but the ability to dynamically create or remove parts of a page requires us to leverage a whole new set of techniques.

Moving Elements

To add an element, we must use the appendChild method of the node that will become the added node's parent. In other words, to add your new element as a child of an existing node in the document, we use that node's appendChild method:

// We'll add the link to the end of the paragraph
var para = document.getElementById('codepara'); ?
para.appendChild(sitepoint_link);

After this, our page will look a little odd. Here's the updated HTML code:

<div id="codesection">
<p id="codepara"> ?
<a href="http://www.google.com/" id="splink">Google</a> ?
</p> ?
<ul> ?
<li></li> ?
<li><a href="http://www.yahoo.com/" id="yalink" ?
>Yahoo!</a></li> ?
</ul> ?
</div>

Another useful thing to know is that, in order to move the node to its new place in the document, we don't have to remove it first. If you use appendChild to insert a node into the document, and that node already exists elsewhere in the document, the node will not be duplicated; instead, it will move from its previous location to the new location at which you've inserted it. We can do the same thing with the Yahoo! link:

para.appendChild(document.getElementById('yalink'));

After this, the page will again be rearranged to match the HTML:

<div id="codesection">
<p id="codepara"> ?
<a href="http://www.google.com/" id="splink">Google</a> ?
<a href="http://www.yahoo.com/" id="yalink">Yahoo!</a> ?
</p> ?
<ul> ?
<li></li> ?
<li></li> ?
</ul> ?
</div>

Figure 2.3 shows the new DOM tree so far.

Figure 2.3. The DOM tree after changes.

What if you didn't want to add your new (or moved) element to the end of that paragraph? In addition to appendChild , each node has an insertBefore method, which is called with two arguments: the node to insert, and the node before which it will be inserted. To move the Yahoo! link to the beginning of the paragraph, we want to insert it as a child of the paragraph that appears before the Google link. So, to insert the Yahoo! link (the first argument) as a child of the paragraph right before the Google link ( sitepoint_link , the second argument), we'd use the following:

para.insertBefore(document.getElementById('yalink'),
sitepoint_link);

Be sure that the second argument ( sitepoint_link ) really is an existing child node of para, or this method will fail.

Throwing Away Elements

Removing an element is very similar to the process of adding one: again, we use the removeChild method on the element's parent node. Remembering from earlier that we can access a given node's parent as node .parentNode, we can remove our sitepoint_link from the document entirely:

// never hurts to be paranoid: check that our node *has* a parent
if (sitepoint_link.parentNode) { ?
sitepoint_link.parentNode.removeChild(sitepoint_link); ?
}

That action will change the HTML code to that shown below:

<div id="codesection">
<p id="codepara"> ?
<a href="http://www.yahoo.com/" id="yalink">Yahoo!</a> ?
</p> ?
<ul> ?
<li></li> ?
<li></li> ?
</ul> ?
</div>

Note

Even after the node's removal, sitepoint_link still constitutes a reference to that link. It still exists, it's just not in the document any more: it's floating in limbo. We can add it back to the document somewhere else if we want to. Set the variable to null to make the deleted element disappear forever.

Creating Elements

Moving existing elements around within the page is a powerful and useful technique (with which you're well on the way to implementing Space Invaders or Pac Man!). But, above and beyond that, we have the ability to create brand new elements and add them to the page, providing the capacity for truly dynamic content. The point to remember is that, as before, a page's text resides in text nodes, so if we need to create an element that contains text, we must create both the new element node and a text node to contain its text. To achieve this, we need two new methods: document.createElement and document.createTextNode .

First, we create the element itself:

var linux_link = document.createElement('a');

Even though we've created the element, it's not yet part of the document. Next, we set some of its properties in the same way that we'd set properties on an existing link:

linux_link.href = 'http://www.linux.org/';

We then create the text node for the text that will appear inside the link. We pass the text for the text node as a parameter:

var linux_tn =
document.createTextNode('The Linux operating system');

The text node is also floating around, separate from the document. We add the text node to the element's list of children, as above:

linux_link.appendChild(linux_tn);

The element and text node now form a mini-tree of two nodes (officially a document fragment ), but they remain separate from the DOM. Finally, we insert the element into the page, which is the same as putting it into the DOM tree:

para.appendChild(linux_link);

Here's the resulting HTML:

<div id="codesection">
<p id="codepara"> ?
<a href="http://www.yahoo.com/" id="yalink">Yahoo!</a> ?
<a href="http://www.linux.org/">The Linux operating system</a> ?
</p> ?
<ul> ?
<li></li> ?
<li></li> ?
</ul> ?
</div>

As you can see, to create elements, we use the same techniques and knowledge – text nodes are children of the element node, we append a child with node.appendChild – we use to work with nodes that are already part of the document. To the DOM, a node is a node whether it's part of the document or not: it's just a node object.

Copying Elements

Creating one element is simple, as we've seen. But what if you want to add a lot of dynamic content to a page? Having to create a whole batch of new elements and text nodes – appending the text nodes to their elements, the elements to each other, and the top element to the page – is something of a laborious process. Fortunately, if you're adding to the page a copy of something that's already there, a shortcut is available: the cloneNode method. This returns a copy of the node, including all its attributes and all its children. (You can elect to clone the node only – not its children – by passing false to the cloneNode method.) If you have a moderately complex piece of HTML that contains many elements, cloneNode is a very quick way to return a copy of that block of HTML ready for insertion into the document:

var newpara = para.cloneNode(true);
document.getElementById('codesection').appendChild(newpara);

You can't rush ahead and just do this, though: it pays to be careful with cloneNode . This method clones all attributes of the node and all its child nodes, including IDs, and IDs must be unique within your document. So, if you have elements with IDs in your cloned HTML block, you need to fix those IDs before you append the cloned block to the document.

It would be nice to be able to grab the Yahoo! link in our cloned block using the following code:

var new_yahoo_link = newpara.getElementById('yalink');

But, unfortunately, we can't. The getElementById method is defined only on a document, not on any arbitrary node. The easiest way around this is to refrain from defining IDs on elements in a block that you wish to clone. Here's a line of code that will remove the Yahoo! link's id :

newpara.firstChild.removeAttribute('id');

We still have the ID on the paragraph itself, though, which means that when we append the new paragraph to the document, we'll have two paragraphs with the ID codepara . This is bad – it's not supposed to happen. We must fix it before we append the new paragraph, revising the above code as follows:

var newpara = para.cloneNode(true);
newpara.id = 'codepara2'; ?
newpara.firstChild.removeAttribute('id'); ?
document.getElementById('codesection').appendChild(newpara);

This code returns the following results:

<div id="codesection">
<p id="codepara"> ?
<a href="http://www.yahoo.com/">Yahoo!</a> ?
<a href="http://www.linux.org/">The Linux operating system</a> ?
</p> ?
<p id="codepara2"> ?
<a href="http://www.yahoo.com/">Yahoo!</a> ?
<a href="http://www.linux.org/">The Linux operating system</a> ?
</p> ?
<ul> ?
<li></li> ?
<li></li> ?
</ul> ?
</div>

As you can see, there's a little bit of surgery involved if you choose to copy big chunks of the document. This demonstration concludes our experimentation with this particular bit of code.

Making an Expanding Form

As our first full example, we'll use the DOM's element creation methods to build a form that can grow as the user fills it. This allows users to add to the form as many entries as they like.

Let's imagine an online system through which people can sign up themselves, and any number of their friends, for free beer. (Maybe there's a mad millionaire philanthropist on the loose. No, I can't give you a URL at which this system is running for real!)

The users add their own names, then the names of all of the friends they wish to invite. Without the DOM, we'd require the form either to contain a large number of slots for friends' names (more than anyone would use), or to submit regularly back to the server to get a fresh (empty) list of name entry areas.

In our brave new world, we can add the extra name entry fields dynamically. We'll place a button on the form that says, Add another friend. Clicking that button will add a new field to the list, ready for submission to the server. Each newly-created field will need a different name attribute, so that it can be distinguished when the server eventually receives the submitted form. (Depending on the server-side language used to process the form, this isn't strictly necessary. Since our example form won't actually submit to anything, we'll implement it as a useful exercise.)

Our form will provide a text entry box for the user's name, a fieldset containing one text entry box for a friend's name, and a button to add more friends. When the button is clicked, we'll add a new text entry box for another friend's name.

Example 2.1. expandingForm.html

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"> ?
<html> ?
<head> ?
<title>Free beer signup form</title> ?

<script type="text/javascript"> ?
var fieldCount = 1; ?
function addFriend() { ?
fieldCount++; ?
var newFriend = document.createElement('input'); ?
newFriend.type = 'text'; ?
newFriend.name = 'friend' + fieldCount; ?
newFriend.id = 'friend' + fieldCount; ?
document.getElementById('fs').appendChild(newFriend); ?
} ?
</script> ?

<style type="text/css"> ?
input { ?
display: block; ?
margin-bottom: 2px; ?
} ?
button { ?
float: right; ?
} ?
fieldset { ?
border: 1px solid black; ?
} ?
</style> ?

</head> ?
<body> ?
<h1>Free beer signup form</h1> ?
<form> ?
<label for="you">Your name</label> ?
<input type="text" name="you" id="you"> ?
<fieldset id="fs"> ?
<legend>Friends you wish to invite</legend> ?
<button onclick="addFriend(); return false;"> ?
Add another friend ?
</button> ?
<input type="text" name="friend1" id="friend1"> ?
</fieldset> ?
<input type="submit" value="Save details"> ?
</form> ?
</body> ?
</html>

Notice our fieldCount variable; this keeps track of how many friend fields there are.

Example 2.2. expandingForm.html (excerpt)

var fieldCount = 1;

When the button is clicked, we run the addFriend function (we'll discuss handling clicks – and various other kinds of events – more in the next chapter):

The addFriend function completes a number of tas ks each time it's run:

Increments the fieldCount :

Example 2.3. expandingForm.html (excerpt)

fieldCount++;

Creates a new input element:

Example 2.4. expandingForm.html (excerpt)

var newFriend = document.createElement('input');

Sets its type to text – we want a text entry box, an element specified by <input type="text"> :

Example 2.5. expandingForm.html (excerpt)

newFriend.type = 'text';

Sets a unique id and name (because the ID must be unique, and all the entry boxes must have different names so they can be distinguished when the form's submitted):

Example 2.6. expandingForm.html (excerpt)

newFriend.name = 'friend' + fieldCount;
newFriend.id = 'friend' + fieldCount;

Adds this newly-created element to the document:

Example 2.7. expandingForm.html (excerpt)

document.getElementById('fs').appendChild(newFriend);

Here's what the page looks like after the "add another friend" button has been clicked twice, and two friends' names have been added:

Figure 2.4. Signing up for free beer.

Free beer, thanks to the power of the DOM. We can't complain about that!

Making Modular Image Rollovers

Image rollover scripts, in which an image is used as a link, and that image changes when the user mouses over it, are a mainstay of JavaScript programming on the Web. Traditionally, they've required a lot of script, and a lot of customization, on the part of the developer. The introspective capability of the DOM – the ability of script to inspect the structure of the page in which it's running – gives us the power to detect rollover images automatically and set them up without any customization. This represents a more systematic approach than the old-fashioned use of onmouseover and onmouseout attributes, and keeps rollover code separate from other content.

We'll build our page so that the links on which we want to display rollover effects have a class of rollover . They'll contain one img element – nothing else. We'll also provide specially named rollover images: if an image within the page is called foo.gif , then the matching rollover image will be named foo_over.gif . When the page loads, we'll walk the DOM tree, identify all the appropriate links (by checking their class and whether they contain an img element), and set up the rollover on each. This specially-named rollover image allows us to deduce the name of any rollover image without saving that name anywhere. It reduces the amount of data we have to manage.

An alternative technique involves use of a non-HTML attribute in the image tag:

However, since oversrc isn't a standard attribute, this approach would cause your HTML to be invalid.

Some of the following script may seem a little opaque: we will be attaching listeners to DOM events to ensure that scripts are run at the appropriate times. If this is confusing, then feel free to revisit this example after you've read the discussion of DOM events in the next chapter.

A Sample HTML Page

First, the HTML: here we have our links, with class rollover , containing the images.

Example 2.8. rollovers.html

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"> ?
<html> ?
<head> ?
<title>Modular rollovers</title> ?
<script type="text/javascript" src="rollovers.js"></script> ?
<style type="text/css"> ?
/* Remove the blue border on the rollover images */ ?
a.rollover img { ?
border-width: 0; ?
} ?
</style> ?
</head> ?
<body> ?
<h1>Modular rollovers</h1> ?
<p>Below we have two links, containing images that we want ?
to change on mouseover.</p> ?
<ul> ?
<li> ?
<a href="" class="rollover" alt="Roll" ?
><img src="basic_image.gif" /></a> ?
</li> ?
<li> ?
<a href="" class="rollover" alt="Roll" ?
><img src="basic_image2.gif"></a> ?
</li> ?
</ul> ?
</body> ?
</html>

The page also includes the JavaScript file that does all the work:

Example 2.9. rollovers.js

The DOM-walking parts of this code are found in setupRollovers and in findTarget , which is called from the two mouseover/mouseout functions. Let's look at each of these in turn.

The setupRollovers Function

The code for the setupRollovers function starts like this:

Example 2.10. rollovers.js (excerpt)

if (!document.getElementsByTagName)
return;

This code confirms that we're in a DOM-supporting browser. If we're not (ie if document.getElementsByTagName , the method, doesn't exist), we exit here and progress no further. If the method does exist, we continue:

Example 2.11. rollovers.js (excerpt)

var all_links = document.getElementsByTagName('a');

Here, we make all_links a reference to a list of all the <a> tags in the document.

Example 2.12. rollovers.js (excerpt)

for (var i = 0; i < all_links.length; i++) {
var link = all_links[i];

The above code iterates through the retrieved list of tags in standard JavaScript fashion. We assign the link variable to each link, as a way to simplify the following code.

Example 2.13. rollovers.js (excerpt)

if (link.className &&
(' ' + link.className + ' ').indexOf(' rollover ') != -1)
{

We need to know whether each link is of class rollover . However, an element may have more than one class; if this tag had two classes, rollover and hotlink , for example, it would have className="rollover hotlink" . This would mean that we could not check for an element having a specific class using the following:

if (element .className == " my class")

If the element has multiple classes, the above condition will always evaluate to false . A useful approach here is to look for the string ' myclass ' (the class name with a space before and after it) in the string ' ' + element.className + ' ' (the element's class attribute with a space before and after it). This will always find your class, as you're expecting. It also avoids a problem with a similar technique, which uses className.indexOf to look for 'myclass' . If the element in question is of class myclassroom , this technique will give a false positive. (Another option is to use a regular expression to spot the class name. In the interests of simplicity, however, we'll stick with the method already presented.)

Example 2.14. rollovers.js (excerpt)

if (link.childNodes &&
link.childNodes.length == 1 &&
link.childNodes[0].nodeName.toLowerCase() == 'img') {

We want to confirm that this link contains nothing but an img element, so we make use of a very handy property of JavaScript, called short-circuit evaluation . In an if statement of the form if (a && b && c) , if a is false, then b and c are not evaluated at all. This means that b and c can be things that depend on a 's trueness: if a is not true, then they are not evaluated, so it's safe to put them into the if statement.

Looking at the above code may make this clearer. We need to test if the nodeName of the link's first child node is img . We might use the following code:

if (link.childNodes[0].nodeName.toLowerCase == 'img')

However, if the current link doesn't have any child nodes, this code will cause an error because there is no link.childNodes[0] . So, we must first check that child nodes exist; second, we confirm that there is one and only one child; third, we check whether that one-and-only first child is an image. We can safely assume in the image check that link.childNodes[0] exists, because we've already confirmed that that's the case: if it didn't exist, we wouldn't have got this far.

Example 2.15. rollovers.js (excerpt)

link.onmouseover = mouseover;

This code attaches an event handler to the mouseover event on a node.

Example 2.16. rollovers.js (excerpt)

link.onmouseout = mouseout;

And this line attaches an event handler to the mouseout event on that node. 就這樣！

The findTarget Function

This little function is called by the mouseover and mouseout functions. As we'll see, they pass event objects to findTarget , which, in return, passes back the link tag surrounding the image that generated the event, if any such tag is to be found.

findTarget

Example 2.17. rollovers.js (excerpt)

var target; ?

if (window.event && window.event.srcElement) ?
target = window.event.srcElement; ?
else if (e && e.target) ?
target = e.target; ?
if (!target) ?
return null;

This first part is related to DOM event handling, which is explained in the next chapter. We'll ignore its workings for now, except to say that it caters for the differences between Internet Explorer and fully DOM-supporting browsers. Once this code has run, however, we should have in our variable target the element that the browser deems to be responsible for the mouseover or mouseout event – ideally the <a> tag.

Example 2.18. rollovers.js (excerpt)

while (target != document.body &&
target.nodeName.toLowerCase() != 'a')
target = target.parentNode;

if (target.nodeName.toLowerCase() != 'a')
return null;

The variable target should be a reference to the <a> tag on which the user clicked, but it may be something inside the <a> tag (as some browsers handle events this way). In such cases, the above code keeps getting the parent node of that tag until it gets to an <a> tag (which will be the one we want). If we find the document body – a <body> tag – instead, we've gone too far. We'll give up, returning null (nothing) from the function, and going no further.

If we did find an <a> tag, however, we return that:

Example 2.19. rollovers.js (excerpt)

return target;
}

The mouseover / mouseout Functions

These functions work in similar ways and do very similar things: mouseover is called when we move the mouse over one of our rollover links, while mouseout is called when we move the mouse out again.

The code for mouseover starts like this:

Example 2.20. rollovers.js (excerpt)

var target = findTarget(e);
if (!target) return;

We call the findTarget function, described above, to get a reference to the link over which the mouse is located. If no element is returned, we give up, degrading gracefully. Otherwise, we have the moused-over <a> tag in target. Next, we dig out the image.

Example 2.21. rollovers.js (excerpt)

var img_tag = target.childNodes[0];

We also know that the <a> tag has one, and only one, child node, and that's an <img> tag. We know this because we checked that this was the case when we set up the event handler in setupRollovers .

Example 2.22. rollovers.js (excerpt)

img_tag.src = img_tag.src.replace(/(.[^.]+)$/, '_over$1');

Images have a src attribute, which you can access through the DOM with the element's src property. In the code snippet above, we apply a regular expression substitution to that string. (Although the full details of regular expressions are beyond the scope of this book, we'll look at the basics in Chapter 6, Forms and Validation . A more detailed resource is Kevin Yank's article on sitepoint.com, Regular Expressions in JavaScript .) Changing the value of an <img> tag's src attribute causes it to reload itself with the new image; thus, making this substitution (replacing something.gif with something_over.gif ) causes the original image to change to the rollover image. The mouseout function does the exact opposite: it changes the reference to something_over.gif in the image's src attribute to something.gif, causing the original image to reappear.

Something for Nothing (Almost)

If you look at the code for this modular rollover, you'll see that it's divided into parts. The setupRollovers function does nothing but install listeners. The findTarget function does nothing but find the link tag for a given event. The mouseover and mouseout functions do little other than the actual image swapping work. The tasks are neatly divided.

That means that this code is good for other applications. We can change the mouseover and mouseout functions to do something else – for example, to make popup help content appear – without needing to start from scratch to get it working. We get to reuse (or at least rip off with minimal change) the other functions in the script. This is not only convenient; it's also neat and clean. We're on the way to a better kind of scripting!

摘要

In the introduction, we referred to the DOM as a critical part of DHTML. Exploring the DOM – being able to find, change, add, and remove elements from your document – is a powerful technique all by itself, and is a fundamental aspect of modern DHTML. Once you've mastered the techniques described in this chapter, everything else will fall into place. Through the rest of the book, we'll be describing techniques and tricks with which you can do wondrous things on your sites, and in your Web applications, using DHTML. They all build upon this fundamental approach of manipulating the Document Object Model.

Chapter 3. Handling DOM Events

When I can't handle events, I let them handle themselves.

–Henry Ford

An event is something that happens, be it in real life, or in DHTML programming. But to those working with DHTML, events have a very specific meaning. An event is generated, or fired, when something happens to an element: a mouse clicks on a button, for example, or a change is made to a form. DHTML programming is all about event handling; your code will run in response to the firing of this or that event.

Learning which events are available, how to hook your code up to them, and how to make best use of them is a critical part of building dynamic Web applications. (It does seem that there are quite a few "critical" bits, I know!) That's what we cover in this chapter, along with a couple of real-world examples.

About Elements and Events

We're using a modern approach to DHTML, so all our DHTML code will be set to run in response to the firing of an event. If you've done any JavaScript Web programming before, you may already be using this technique without knowing it. Let's look at the procedure by which code has traditionally been hooked up to events, learn how to do it under the DOM (and why the DOM method is better), and find out exactly what these techniques make possible.

Common Events

Every page element fires a given selection of events. Some events are common to all elements; others are more specific. For example, all visible elements will fire a mouseover event when the mouse is moved over them. A change event, however, will only be fired by elements whose contents can be changed: text boxes, text areas, and drop-down lists.

You might have noticed above that I used mouseover, rather than onmouseover , for the event name. Even though the HTML attribute for handling this event is onmouseover , the modern way to describe the event itself is simply mouseover. This allows us to talk about the event (mouseover) and the event handler ( onmouseover ) separately. The event handler is the location at which an event handler is placed. In the bad old browser days, these concepts were all mixed up, but now we can safely think of them as separate entities.

The documents that describe the events fired by a given element are the W3C DOM specifications and HTML recommendations, which were mentioned in the last chapter, as well as the W3C DOM 2 Events specification . There's also some extra information on key events in the DOM 3 Events specification .

A summary of the events that you're likely to find useful, and that have cross-browser support, is given in Table 3.1. Note that this isn't an exhaustive survey: it's a listing of events that you're likely to use often, rather than everything under the sun.

Table 3.1. Useful Events.

Click to popup a larger image of this table.

Hooking Code to Events

So, now you know some common events, and when they fire. But how do you make your code run in response to those events?

Hooking up the Old Way

If you've done any JavaScript coding before, you'll probably have written something like this:

<a href="somewhere.html"
onclick="myJavaScriptFunction(); return false;" ?
>click me!</a>

That onclick attribute connects some JavaScript code to that link's click event. When the link is clicked, it will fire a click event, and that code will run. 沒問題！ Notice, though, that the code never actually mentions "click," which is the actual name of the event.

What if we wanted to detect a keypress? Here's the equivalent script:

function aKeyWasPressed() {
// put event handler code here ... ?
}

And here's the matching snippet of HTML:

In this case, how does our aKeyWasPressed function know which key was pressed? 好吧，事實并非如此。 That's a major limitation of the old-fashioned approach. But we can improve on that!

Hooking up the DOM Way

The DOM specifications enlarge the idea of event handlers by providing event targets and event listeners . An event target is the thing at which an event is aimed – an element, essentially. An event listener is the thing that grabs the event when it appears, and responds to it. Where do events come from in the first place? They come from the user. The browser software captures the user action and sends the event to the right event target.

A given event source can be relevant to more than one event listener. Using the old-fashioned method above, only one piece of code could be run in response to any event. For example, an element could have only one onclick attribute. (Actually, you could have as many as you liked, but each one would overwrite the one before it, so, effectively, you have only one. Alternatively, you could string JavaScript statements together, using semicolons in the attribute, but this makes the HTML code even more cluttered.) Using the modern method, you can run as many pieces of code as you want upon the firing of an event or events. Listeners get to share events, and events get to share listeners. To facilitate this, we must move our "hookup" code from the HTML to a separate script section: as noted above, no element can have more than one onclick attribute.

Event handling works in different ways, depending on the browser. We'll examine the W3C-approved way first, before we look at event handling in Internet Explorer. Here's the W3C approach.

Example 3.1. keycodedetect.html (excerpt)

function aKeyWasPressed(e) {
// put event listener code here... ?
} ?

var textarea = document.getElementById('myta'); ?
textarea.addEventListener('keyup', aKeyWasPressed, false);

And here's the matching bit of HTML:

Example 3.2. keycodedetect.html (excerpt)

HTML Before Script… for Now

If you're working through this example in your HTML editor of choice, be sure to place the JavaScript code after the HTML in this and the next few examples in this chapter. The textarea must exist before the JavaScript code can assign an event listener to it.

If you're used to placing JavaScript at the top of your HTML files, don't fret. We'll discuss an elegant way around this restriction at the end of the section.

Those few lines of code contain a number of complex concepts. Consider this snippet:

Example 3.3. keycodedetect.html (excerpt)

var textarea = document.getElementById('myta');

Here, we see a familiar reference to the <textarea> . Next, there's something new:

Example 3.4. keycodedetect.html (excerpt)

textarea.addEventListener('keyup', aKeyWasPressed, false);

This is the crucial line that sets everything up. Each element has an addEventListener method, which allows you to hook a function to any event that the element receives. (We've used the keyup event here, rather than the more commonly expected keypress, because, at the time of writing, Safari on Macintosh does not support the assigning of keypress events using addEventListener . Perhaps more importantly, the DOM3 recommendation does not mention a keypress event.) The method takes three arguments: the event, the function that should be called, and a true-or-false value for useCapture . This last item relates to a rarely-used feature of DOM events called event capture . For the moment, we'll just set it to false , to indicate that we don't want to use event capture. If you'd like to get the full story, see the DOM Level 3 Events specification (not for the faint of heart!).

The event is specified as a string, which is the (modern) name of the event (ie without the "on" prefix). The function is specified using only the name of the function; do not place brackets after it, as in aKeyWasPressed() , as this would call the function. We don't want to call it now; we want to call it later, when the event is fired. (If you have worked in other languages, you may recognize that this means that functions are first-class objects in JavaScript; we can pass around references to a function using its name, but without calling it. This procedure doesn't work in all languages, but it's a very useful feature of JavaScript.)

Now, when a key is pressed in our <textarea> , our aKeyWasPressed function will be called. Note that JavaScript no longer clutters up our HTML; much like the separation of design and content facilitated by CSS, we've separated our page content (HTML) from our page behavior (JavaScript) . This is an important benefit of the new technique: we can switch new event listeners in and out without altering the HTML in our page. It's the modern way!

We still haven't addressed the question we posed earlier, though: how does the aKeyWasPressed function know which key was pressed?

Getting Event Information

A subtle change that we made in the above code was to give the aKeyWasPressed function an argument, e .

Example 3.5. keycodedetect.html (excerpt)

function aKeyWasPressed(e) {
...

When a function is called as an event listener, it is passed, in the case of a W3C events-compliant browser, to an event object , which holds details of the event. This object has a number of properties containing useful information, such as target, and a reference to the element that fired the event. The precise properties that are available will depend on the type of event in question, but the most useful properties are listed in Table 3.2.

Table 3.2. Useful Properties.

Click to popup a larger image of this table.

[a] Don't use charCode here, even though some Websites tell you to. keyCode has good cross-browser support, and charCode does not. Key codes in the DOM are a standards mess! There are three ways to get the code: keyCode (IE), charCode (Mozilla/Netscape) and data (the official DOM 3 Events way). Fortunately, all major browsers support the nonstandard keyCode. So always use this, at least until the data property is widespread (in about 2010!).

Code that identifies which key was pressed would look like this:

Example 3.6. keycodedetect.html (excerpt)

function aKeyWasPressed(e) {
var key = e.keyCode; ?
alert('You pressed the key: ' + String.fromCharCode(key)); ?
} ?
var textarea = document.getElementById('myta'); ?
textarea.addEventListener('keyup', aKeyWasPressed, false);

When a key is pressed, our function will pop up a dialog box to tell us so. (Note that we use the String.fromCharCode method to convert the keyboard code provided by keyCode to a human-readable string.)

Re-using Listeners Across Targets

The target attribute might not seem very useful; after all, we know that it will be a reference to the <textarea> . But we can hook up the same function as an event listener on more than one element. We can, for example, attach one single function as an event listener for click events to every link in our page. When any link is clicked, our function will be called; we can then tell which link was clicked by examining the function's e.target . We'll come back to this in later examples in this chapter.

For now, all we need to know is that we don't have to write a separate event listener for every single tag in which we're interested.

What Happens After an Event Fires?

Events have two further important properties: bubbling and default actions . Think about an HTML document. It's hierarchical: elements are contained by other elements. Consider this HTML snippet:

Clicking on the link will cause that link to fire a click event. But the link is contained within the paragraph, and the paragraph is contained within the <div> . So clicking the link will also cause both the paragraph and the <div> to see the click event. This is called event bubbling ; an event "bubbles" up through the DOM tree, starting with the target element, until it reaches the top. Not all events bubble; for example, focus and blur events do not. Bubbling can often be ignored, but there are times when you'll want to prevent a specific event from bubbling. (There are a lot of complex rules about event bubbling and event capturing, the phase of event propagation that occurs before event bubbling. In practice, we don't need to know much beyond how to stop it happening, but a complete write-up is available at for those who would like to know more of the theory underlying this aspect of the DOM.)

Once you've got an event, the DOM Events specification says that you can stop any further bubbling like this:

function aKeyWasPressed(e) {
var key = e.keyCode; ?
e.stopPropagation(); ?
... ?
}

Once the call to topPropagation is in place, the event will occur on the <a> tag only: any listeners on the <p> or <div> tags will miss out. If there are no listeners on those other tags, there's no need to stop bubbling. In this case, the event silently passes through the parent tags, having no extra effect.

Some events have a default action. The most obvious example is clicking a link: the default action for this event is to navigate the current window or frame to the link's destination. If we wanted to handle clicks on a link entirely within our JavaScript code, we might want to prevent that default action from being taken.

In our examples so far, we have handled the keyup event, which is fired when a key is released. As it turns out, this event has no default action. A closely-related event that does have a default action is keypress, which occurs whenever a character is typed using the combination of keydown and keyup. The keypress event is nonstandard (ie it is not described by the W3C DOM standard), which is why I have avoided mentioning it until now, but it is well supported by the major browsers.

Let's say we want to prevent keypress events from inputting text into our textarea . We could do this by setting up an event listener that cancelled the default action of that type of event. The DOM standard specifies a method, named preventDefault , that achieves this, but again, Internet Explorer implements its own proprietary technique. Here's the DOM approach:

function aKeyWasPressed(e) {
e.preventDefault(); ?
} ?
var textarea = document.getElementById('myta'); ?
textarea.addEventListener('keypress', aKeyWasPressed, false);

Assigning Event Listeners on Page Load

In all of the examples we've seen so far in this chapter, the JavaScript code has had to follow the HTML code to which it assigns event listeners. If the JavaScript code were to come first, it would be unable to find the HTML elements in question, as they would not yet exist.

A solution to this problem is to assign event listeners for specific document elements in a listener assigned to the window's load event. As a result, event listeners will only be assigned once the document has finished loading, and all elements are available.

Here's the complete listing for our keystroke detection example, restructured in this way:

Example 3.7. keycodedetect.html

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"> ?
<html> ?
<head> ?
<title>Detect keystrokes</title> ?
<script type="text/javascript"> ?
function aKeyWasPressed(e) { ?
var key = e.keyCode; ?
alert('You pressed the key: ' + String.fromCharCode(key)); ?
} ?

function addListeners(e) { ?
var textarea = document.getElementById('myta'); ?
textarea.addEventListener('keyup', aKeyWasPressed, false); ?
} ?

window.addEventListener('load', addListeners, false); ?
</script> ?
</head> ?
<body> ?
<form> ?
<textarea id="myta"></textarea> ?
</form> ?
</body> ?
</html>

Our main event listener, aKeyWasPressed , has not been changed. What has changed is the way in which this listener is assigned. The code that assigns it has been placed inside a new function, addListeners :

Example 3.8. keycodedetect.html (excerpt)

function addListeners(e) {
var textarea = document.getElementById('myta');
textarea.addEventListener('keyup', aKeyWasPressed, false);
}

This function is itself an event listener, which we assign to the window object's load event:

Example 3.9. keycodedetect.html (excerpt)

window.addEventListener('load', addListeners, false);

This event is fired once the document has finished loading, to signal that all HTML elements are now available. The addListeners function takes this opportunity to assign listeners to elements as required.

We'll continue to use this structure as we move forward through this chapter, and the rest of the book.

Making Events Work Cross-Browser

Naturally, making events work cross-browser is not as easy as just following the DOM standard. Internet Explorer doesn't implement the DOM Events model very well. Instead, it offers a proprietary and different way to hook up event listeners and gain access to event data.

Adding Event Listeners Portably

Instead of using an addEventListener method on an element, IE has an attachEvent method, and instead of passing an event object to each event listener, it has a global event object in window.event. This is inconvenient but not catastrophic; it just means that you have to take different actions for different browsers. In practice, what this means is that you have a small number of standard functions and techniques that you use to carry out event handling actions. One of these is the addEvent function, created by Scott Andrew:

Example 3.10. portabledetect.php (excerpt)

IE's attachEvent method is called, with an event name and a function to be the listener, but the event name should have "on" at the beginning. The addEvent function above takes care of the cross-browser differences (Note that if the browser doesn't support either addEventListener or attachEvent , which is the case for IE5 for Macintosh, the code assigns the event listener directly to the element as an event handler using its on event property. This will overwrite any previous event handler that was attached to that event, which isn't good, but it's an interim solution (and better than it not working at all). There is a way around this issue, which, though it makes the code significantly more complex, does avoid this problem; details can be found in this Stylish Scripting blog post ; simply include it in your code, then use it to attach events. As such, the code above becomes:

We're now using the addEvent function to make aKeyWasPressed listen for keyup events on the textarea .

Inspecting Event Objects Portably

This is not the only change that's required; we also have to take into account the fact that IE doesn't pass an event object to our event listener, but instead stores the event object in the window object. Just to make our lives as DHTML developers a little more complex, it also uses slightly different properties on the event object that it creates. These are shown in Table 3.3.

Table 3.3. W3C Event Object Properties.

Click to popup a larger image of this table.

[a] 0 = left button; 2 = right button; 1 = middle button.

[b] 1 = left button; 2 = right button; 4 = middle button. For combinations, add numbers: 7 means all three buttons pressed.

As previously noted, the standard data property is not well supported.

Taking all this into consideration, our portable code becomes:

Example 3.11. portabledetect.html (excerpt)

This updated version of aKeyWasPressed first checks whether a window.event object exists:

Example 3.12. portabledetect.html (excerpt)

if (window.event) {

If it does, then it and its corresponding window.event.keyCode property, are used to obtain the code of the pressed key. (This technique for checking that something exists is called feature sniffing , and will be explained in more detail in the next chapter.) If not, the event object passed to the function (as e ), which also has a keyCode property, is used.

Stopping Propagation and Default Actions Portably

Halting bubbling can be done in two ways, as is the case with much event handling: via the DOM approach and the Internet Explorer approach. In DOM-compliant browsers, we can prevent an event from bubbling by calling the event object's stopPropagation method inside the event listener.

In Internet Explorer (where there is a global window.event object), we set window.event.cancelBubble to true inside the event listener. In practice, the usual technique is to use feature sniffing to Do The Right Thing:

if (window.event && window.event.cancelBubble) {
window.event.cancelBubble = true; ?
} ?
if (e && e.stopPropagation) { ?
// e is the event object passed to this listener ?
e.stopPropagation(); ?
}

Unfortunately, even this doesn't cover all the major browsers. Arguably a worse offender even than Internet Explorer, Apple's Safari browser provides the stopPropagation method, but doesn't actually do anything when it is called. There is no easy way around this, but since event bubbling will not significantly affect any of the examples in this book, we'll just ignore this problem for now.

We also need to feature-sniff to stop default actions. With the DOM, we use the passed event object's preventDefault method; with Internet Explorer, we set the global event object's returnValue property to false .

if (window.event && window.event.returnValue) {
window.event.returnValue = false; ?
} ?
if (e && e.preventDefault) { ?
e.preventDefault(); ?
}

Again, Safari appears to support preventDefault , but doesn't actually do anything when it is called. Unfortunately, preventing the default action associated with an event is a rather vital feature for many of the examples we'll look at in this book. The only way to do it in Safari (at least until Apple fixes its DOM standard event support) is to use an old-style event handler that returns false .

For example, to prevent the click event of a link from navigating to the target of the link, we would normally just use an event listener that prevented the default action of the link:

To make this work in Safari, we need a second function, which will return false to cancel the event, and which we will assign as the onclick event handler of the link:

This is actually quite an ugly solution, as it will overwrite any onclick event handler that another script may have installed. This kind of inter-script conflict is what modern event listeners are designed to avoid. Unfortunately, there is simply no better way around the problem in Safari. We'll see an example of this solution in practice later in this chapter.

This sort of cross-browser coding is obviated to a large extent by browser manufacturers coming together to implement the W3C DOM, but for event handling it's still required.

Smart Uses of Events

That's enough about how events work. Let's see a couple of practical examples. You should also know enough now to fully understand the image rollover code we saw in Chapter 2, The Document Object Model.

Creating Smarter Links

Some Websites open all clicked links in a new window. Often, they do this with the intention that the user will return to their site more readily if it's still open in another browser window. Some users find this useful; others find it heartily annoying. It would be possible, given our event-handling techniques above, to give them the choice.

Imagine we placed a checkbox on the page, which, initially unchecked, was accompanied by the label Open links in new window. Clicking any link will open that link in a new window if the box is checked.

We could implement this functionality using a combination of event listeners: we attach to each link on the page a click listener, which investigates the checkbox and opens the corresponding link in a new window if the box is checked. We also need a listener to run upon page load, to actually attach the listener to each link.

First, here's the HTML page we'll work on:

Example 3.13. smartlinks.html

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"> ?
<html> ?
<head> ?
<title>Smart Links</title> ?
<script type="text/javascript" src="smartlink.js"></script> ?
<style type="text/css"> ?
form { ?
float: right; ?
width: 25em; ?
height: 5em; ?
border: 1px solid blue; ?
padding: 1em; ?
} ?
</style> ?
</head> ?
<body> ?
<h1>Smart Links</h1> ?
<form action=""><p> ?
<label for="newwin">Open links in new window? ?
<input type="checkbox" id="newwin"> ?
</label> ?
</p></form> ?

<p>This page contains several links, such as ?
<a href="http://www.sitepoint.com/">SitePoint</a>, ? ?
<a href="http://www.yahoo.com/">Yahoo!</a>, and ?
<a href="http://www.google.com/">Google</a>. ?
These links should ordinarily open in the same window when ?
clicked, unless the checkbox is checked; this will make them ?
open in a new window. ?
</p> ?
</body> ?
</html>

As you can see, this page is quite simple, and contains no JavaScript except for the file that the <script> tag brings in. Figure 3.1 shows how the code displays:

Figure 3.1. The example "smart links" Web page.

Next, let's look at the content of smartlink.js . This code has been assembled from our earlier discussions, although it contains some extra code for this particular page. First, here's an outline of what the script holds:

Example 3.14. smartlink.js (excerpt)

function addEvent(elm, evType, fn, useCapture) { ... }
function handleLink(e) { ... } ?
function cancelClick() { ... } ?
function addListeners(e) { ... } ?

addEvent(window, 'load', addListeners, false);

And here are those four items in detail:

Example 3.15. smartlink.js

Our code includes the now-familiar addEvent function to carry out cross-browser event hookups. We use it to call the addListeners function once the page has loaded.

The addListeners function uses another familiar technique; it iterates through all the links on the page and does something to them. In this case, it attaches the handleLink function as a click event listener for each link, so that when a link is clicked, that function will be called. It also attaches the cancelClick function as the old-style click event listener for each link – this will permit us to cancel the default action of each link in Safari.

When we click a link, that link fires a click event, and handleLink is run. The function does the following:

Example 3.16. smartlink.js (excerpt)

if (window.event && window.event.srcElement)
el = window.event.srcElement;
if (e && e.target)
el = e.target;
if (!el)
return;

This is the cross-browser approach to identifying which link was clicked; we check for a window.event object and, if it exists, use it to get window.event.srcElement , the clicked link. Alternatively, if e , the passed-in parameter, exists, and e.target exists, then we use that as the clicked link. If we've checked for both e and e.target , but neither exists, we give up and exit the function (with return ).

Next up, we want to make sure that we have a reference to our link element:

Example 3.17. smartlink.js (excerpt)

while (el.nodeName.toLowerCase() != 'a' &&
el.nodeName.toLowerCase() != 'body')
el = el.parentNode;
if (el.nodeName.toLowerCase() == 'body')
return;

Some browsers may pass the text node inside a link as the clicked-on node, instead of the link itself. If the clicked element is not an <a> tag, we ascend the DOM tree, getting its parent (and that node's parent, and so on) until we get to the a element. (We also check for body , to prevent an infinite loop; if we get as far up the tree as the document body , we give up.)

Note that we also use toLowerCase on the nodeName of the element. This is the easiest way to ensure that a browser that returns a nodeName of A , and one that returns a nodeName of a , will both be handled correctly by the function.

Next, we check our checkbox:

Example 3.18. smartlink.js (excerpt)

if (document.getElementById('newwin') &&
document.getElementById('newwin').checked) {

We first confirm (for paranoia's sake) that there is an element with id newwin (which is the checkbox). Then, if that checkbox is checked, we open the link in a new window:

Example 3.19. smartlink.js (excerpt)

window.open(el.href);

We know that el , the clicked link, is a link object, and that link objects have an href property. The window.open method creates a new window and navigates it to the specified URL.

Finally, we take care of what happens afterward:

Example 3.20. smartlink.js (excerpt)

if (window.event) {
window.event.cancelBubble = true;
window.event.returnValue = false;
}
if (e && e.stopPropagation && e.preventDefault) {
e.stopPropagation();
e.preventDefault();
}
}

We don't want the link to have its normal effect of navigating the current window to the link's destination. So, in a cross-browser fashion, we stop the link's normal action from taking place.

As previously mentioned, Safari doesn't support the standard method of canc elling the link's default action, so we have an old-style event listener, cancelClick , that will cancel the event in that browser:

Example 3.21. smartlink.js (excerpt)

function cancelClick() {
if (document.getElementById('newwin') && ?
document.getElementById('newwin').checked) { ?
return false; ?
} ?
return true; ?
}

You can see that some of this code is likely to appear in every project we attempt, particularly those parts that have to do with listener installation.

Making Tables More Readable

A handy trick that many applications use to display tables of data is to highlight the individual row and column that the viewer is looking at; paper-based tables often shade table rows and columns alternately to provide a similar (although non-dynamic(…until paper technology gets a lot cooler than it is now, at any rate!) effect.

Here's a screenshot of this effect in action. Note the location of the cursor. If we had another cursor, you could see that the second table is highlighted differently. But we don't, so you'll just have to try the example code for yourself…

Figure 3.2. Example of table highlighting in a Web page.

We can apply this effect to tables in an HTML document using event listeners. We'll attach a mouseover listener to each cell in a table, and have that listener highlight all the other cells located in that cell's row and column. We'll also attach a mouseout listener that turns the highlight off again.

The techniques we have explored in this chapter are at their most powerful when we combine the dynamic capabilities of DHTML with the page styling of CSS. Instead of specifically applying a highlight to each cell we wish to illuminate, we'll just apply a new class, hi , to those cells; our CSS will define exactly how table cells with class hi should be displayed. To change the highlight, simply change the CSS. For a more powerful effect still, use CSS's selectors to apply different styles to highlighted cells depending on the table in which they appear.

Here's an example page that contains tables:

Example 3.22. tableHighlight.html

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"> ?
<html> ?
<head> ?
<title>Highlighted Tables</title> ?
<script type="text/javascript" src="tableHighlight.js"> ?
</script> ?
<style type="text/css"> ?
tr.hi td, td.hi { ?
background-color: #ccc; ?
} ?
table.extra tr.hi td, table.extra td.hi { ?
color: red; ? ?
text-decoration: underline overline; ?
background-color: transparent; ?
} ?
</style> ?
</head> ?
<body> ?
<h1>Highlighted Tables</h1> ?

<h2>A table with highlighting</h2> ?
<table> ?
<tr> ?
<td></td> ?
<td>Column 1</td> ?
<td>Column 2</td> ? ?
<td>Column 3</td> ?
<td>Column 4</td> ?
</tr> ?
<tr> ?
<td>Row 1</td> ?
<td>1,1</td><td>1,2</td><td>1,3</td><td>1,4</td> ?
</tr> ?
<tr> ?
<td>Row 2</td> ?
<td>2,1</td><td>2,2</td><td>2,3</td><td>2,4</td> ?
</tr> ?
<tr> ?
<td>Row 3</td> ?
<td>3,1</td><td>3,2</td><td>3,3</td><td>3,4</td> ?
</tr> ?
<tr> ?
<td>Row 4</td> ?
<td>4,1</td><td>4,2</td><td>4,3</td><td>4,4</td> ?
</tr> ?
</table> ?

<h2>A table with different highlighting</h2> ?
<table class="extra"> ?
<tr> ?
<td></td> ?
<td>Column 1</td> ?
<td>Column 2</td> ?
<td>Column 3</td> ?
<td>Column 4</td> ?
</tr> ?
<tr> ?
<td>Row 1</td> ?
<td>1,1</td><td>1,2</td><td>1,3</td><td>1,4</td> ?
</tr> ?
<tr> ?
<td>Row 2</td> ?
<td>2,1</td><td>2,2</td><td>2,3</td><td>2,4</td> ?
</tr> ?
<tr> ?
<td>Row 3</td> ?
<td>3,1</td><td>3,2</td><td>3,3</td><td>3,4</td> ?
</tr> ?
<tr> ?
<td>Row 4</td> ?
<td>4,1</td><td>4,2</td><td>4,3</td><td>4,4</td> ?
</tr> ?
</table> ?
</body> ?
</html>

That code creates two four-by-four tables, each with column and row headings (so each table contains five rows and five columns in total). Notice that none of the styles have any effect because, as yet, there are no elements with class="hi" .

Let's look at the matching tableHighlight.js script. Its structure reflects our earlier discussions, but it contains some additional code for this particular technique. Here's an outline of the script:

Example 3.23. tableHighlight.js (excerpt)

function addEvent(elm, evType, fn, useCapture) { ... }
function ascendDOM(e, target) { ... } ?
function hi_cell(e) { ... } ?
function lo_cell(e) { ... } ?
function addListeners() { ... } ?

addEvent(window, 'load', addListeners, false);

Notice how similar the function outline is to the smart links example. Here are the six items in all their detail.

Example 3.24. tableHighlight.js

We add our mouseover and mouseout event listeners using the standard approach. The addListeners function sets up our hi_cell and lo_cell functions as mouseover and mouseout event listeners, respectively.

To minimize duplicate code, we've added a handy little utility function called ascendDOM . This marches up the tree from the element supplied in the first argument to find the first enclosing tag whose name matches the second argument.

Processing happens as follows. Mousing over a table cell triggers the hi_cell function. This finds the moused-over cell, then calculates the row and the table in which that cell appears. The ascendDOM function is called quite often in the code, so you can see the benefit of putting that code into a function. In hi_cell , the lines that actually do the styling work are these:

Example 3.25. tableHighlight.js (excerpt)

parent_row.className += ' hi';

Example 3.26. tableHighlight.js (excerpt)

cell.className += ' hi';

The rest of the code is simply concerned with picking out the right elements for these lines to work on.

Our intention here is to apply the class hi to the other cells in the row that contains the moused-over cell, and its column. The first line above executes the first task. The second line applies the class to a given cell, but our script needs to find the appropriate cells first.

This is where things get a little complicated. The row is a simple <tr> tag, whereas the column is a list of cells scattered across all the rows in the table. According to the DOM Level 2 specification, table cell elements have a cellIndex property, which indicates the cell's index in the row. To find the other cells in this column, we could iterate through all the rows in the table and find within each row the cell that has the same cellIndex .

Sadly, Safari doesn't properly support cellIndex – it is always set to 0 , no matter what the actual index should be. If Safari supported cellIndex , the process could have been simple:

var ci = el.cellIndex;

In fact, this concise snippet must be replaced with the much longer section below:

Example 3.27. tableHighlight.js (excerpt)

var ci = -1;
for (var i = 0; i < parent_row.cells.length; i++) {
if (el === parent_row.cells[i]) {
ci = i;
}
}
if (ci == -1) return; // this should never happen

ci is the cellIndex , and can be used to highlight other cells with the same cellIndex in the other rows in the table:

Example 3.28. tableHighlight.js (excerpt)

for (var i = 0; i < parent_table.rows.length; i++) { ?
var cell = parent_table.rows[i].cells[ci]; ?
cell.className += ' hi'; ?
}

All the table's rows are held in the table's rows array. We walk through that array, applying the hi class to the cell in each row that has the same index as the moused-over cell.

The upshot of this exercise is that all the cells in the same column as the moused-over cell will have class hi ; the table row containing the cell will also have class hi .

Our CSS code takes care of the appearance of these cells:

Example 3.29. tableHighlight.html (excerpt)

tr.hi td, td.hi {
background-color: #ccc;
}

We've applied a background color of class hi to both td s, and tds in a tr of class hi ; thus, these cells will be highlighted. The lo_cell function works similarly, except that it removes the class hi from the row and column rather than applying it. The removal is done with the following lines:

Example 3.30. tableHighlight.js (excerpt)

parent_row.className =
parent_row.className.replace(/b ?hib/, '');

Example 3.31. tableHighlight.js (excerpt)

cell.className = cell.className.replace(/b ?hib/, '');

Since a className is a string, it has all the methods of a string, one of which is replace ; we can call the replace method with a regular expression (first parameter) and a substitute string (second parameter). If a match for the regular expression is found in the string, it is replaced by the substitute string. In our example, we look for matches to the expression b ?hib (note that regular expressions are delimited by slashes, not quotes) – that is, a word boundary followed by an optional space, the word 'hi', and another word boundary – and replace it with a blank string, thus removing it from the className.

An added bonus of using CSS to provide the style information is that we can apply different highlighting to different tables on the page without changing the script. For example, the HTML of the page contains two tables, one with a class of extra . We apply some CSS specifically to tables with class extra :

Example 3.32. tableHighlight.html (excerpt)

table.extra tr.hi td, table.extra td.hi {
color: red; ? ?
text-decoration: underline overline; ? ?
background-color: transparent; ? ?
}

As a result, the highlighted cells in that particular table will be highlighted differently. CSS makes achieving this kind of effect very easy.

摘要

Understanding the processes by which events are fired, and by which code is hooked to those events, is vital to DHTML programming. Almost everything you do in DHTML will involve attaching code to events, as described in this chapter. We've examined some common events and the two browser models for listening to them. We have also covered what happens when an event fires, and how you can interrupt or alter that process. Finally, we looked at a few events in detail, and saw some simple examples of how code can attach to those events and improve the user experience on sites that employ these techniques.

Chapter 4. Detecting Browser Features

You just listed all my best features.

–The Cat, Red Dwarf , Series 3, Episode DNA

An important design constraint when adding DHTML to your Websites is that it should be unobtrusive. By "unobtrusive," I mean that if a given Web browser doesn't support the DHTML features you're using, that absence should affect the user experience as little as possible. Errors should not be shown to the user: the site should be perfectly usable without the DHTML enhancements. The browsers that render your site will fall into the following broad categories:

Offer no JavaScript support at all, or have JavaScript turned off.

Provide some JavaScript support, but modern features are missing.

Have full JavaScript support, but offer no W3C DOM support at all.

Provide incomplete DOM support, but some DOM features are missing or
buggy.

Offer complete DOM support without bugs.

The first and the last categories hold no concerns for you as a DHTML developer. A browser that does not run JavaScript at all will simply work without calling any of your DHTML code, so you can ignore it for the purposes of this discussion. You just need to make sure that your page displays correctly when JavaScript is turned off. (For example, if your DHTML shows and hides some areas of the page, those areas should show initially, then be hidden with DHTML, so that they are available to non-DHTML browsers.) Similarly, a browser that implements the DOM completely and without bugs would make life very easy. It's a shame that such browsers do not exist.

The three categories in the middle of the list are of concern to us in this chapter. Here, we'll explore how to identify which DHTML features are supported by a given browser before we try to utilize those features in running our code.

There are basically two ways to working out whether the browser that's being used supports a given feature. (Actually, there's a third way to identify browser support. The DOM standards specify a document.implementation.hasFeature method that you can use to detect DOM support. It's rarely used, though.) The first approach is to work out which browser is being used, then have a list within your code that states which browser supports which features. The second way is to test for the existence of a required feature directly. In the following discussion, we'll see that classifying browsers by type isn't as good as detecting features on a case-by-case basis.

Old-Fashioned Browser Sniffing

In the bad old days, before browser manufacturers standardized on the DOM, JavaScript developers relied on detection of the browser's brand and version via a process known as browser sniffing. Each browser provides a window.navigator object, containing details about the browser, which can be checked from JavaScript. We can, for example, find the name of the browser (the "user agent string") as follows:

var browserName = navigator.userAgent;
var isIE = browserName.match(/MSIE/); // find IE and look-alikes

Don't do this any more! This technique, like many other relics from the Dark Ages of JavaScript coding (before the W3C DOM specifications appeared), should not be used . Browser sniffing is flaky and prone to error, and should be avoided like the black plague. Really : I'm not kidding here.

Why am I so unenthusiastic about browser sniffing? There are lots of reasons. Some browsers lie about, or attempt to disguise, their true details; some, such as Opera, can be configured to deliver a user agent string of the user's choice. It's pretty much impossible to stay up-to-date with every version of every browser, and it's definitely impossible to know which features each version supported upon its release. Moreover, if your site is required to last for any reasonable period of time, new browser versions will be released after your site, and your browser-sniffing code will be unable to account for them. Browser sniffing – what little of it remains – should be confined to the dustbin of history. Put it in the "we didn't know any better" category. There is a significantly better method available: feature sniffing.

Modern DOM Feature Sniffing

Instead of detecting the user's browser, then working out for yourself whether it supports a given feature, simply ask the browser directly whether it supports the feature. For example, a high proportion of DHTML scripts use the DOM method getElementById . To work out whether a particular visitor's browser supports this method, you can use:

if (document.getElementById) {
// and here you know it is supported ? ?
}

If the if statement test passes, we know that the browser supports the feature in question. It is important to note that getElementById is not followed by brackets! We do not say:

if (document.getElementById())

If we include the brackets, we call the method getElementById . If we do not include the brackets, we're referring to the JavaScript Function object that underlies the method. This is a very important distinction. Including the brackets would mean that we were testing the return value of the method call, which we do not want to do. For a start, this would cause an error in a non-DOM browser, because we can't call the getElementById method there at all - it doesn't exist! When we test the Function object instead, we're assessing it for existence. Browsers that don't support the method will fail the test. Therefore, they will not run the code enclosed by the if statement; nor will they display an error.

This feature of JavaScript - the ability to test whether a method exists - has been part of the language since its inception; thus, it is safe to use it on even the oldest JavaScript-supporting browsers. You may recall from the previous chapter the technique of referring to a Function object without calling it. In Chapter 3, Handling DOM Events , we used it to assign a function as an event listener without actually calling it. In JavaScript, everything can be treated as an object if you try hard enough; methods are no exception!

Which DOM Features Should We Test?

The easiest approach is to test for every DOM method you intend to use. If your code uses getElementById and createElement , test for the existence of both methods. This will cover browsers in the fourth category above: the ones that implement some - but not all - of the DOM.

It is not reasonable to assume that a browser that supports getElementById also supports getElementsByTagName . You must explicitly test for each feature.

Where Should We Test for DOM Features?

An easy way to handle these tests is to execute them before your DHTML sets up any event listeners. A large subset of DHTML scripts work by setting on page load some event listeners that will be called as various elements in the browser fire events. If, before setting up the event listeners, you check that the browser supplies all the DOM features required by the code, event listeners will not be set up for browsers that do not support those features. You can therefore reasonably assume in setting up your event listeners that all the features you require are available; this assumption can simplify your code immensely. Here's an example:

This script contains a myScriptInit function, which sets up myScriptEventListener as an event listener. But, before we set up that listener, we check for the existence of the DOM methods getElementById , getElementsByTagName , and createElement .

The if statement says: "if the JavaScript Function object document.getElementById does not exist, or if the Function object document.getElementsByTagName does not exist, or if the Function object document.createElement does not exist, exit the myScriptInit function." This means that, should any of those objects not be supported, the myScriptInit function will exit at that point: it will not even get as far as setting up the event listeners. Our code will set up listeners only on browsers that do support those methods. Therefore, as above, the listener function myScriptEventListener can feel safe in using document.getElementById without first checking to ensure that it is supported. If it wasn't supported, the listener function would not have been set up.

All this sniffing relies on JavaScript's runtime behavior. Even though the scripts are read by the browser at load time, no checks are done on the objects stated in the scripts until the code is run. This allows us to put browser objects in all scripts, and use them only when our detection code gets around to it: an arrangement called late binding .

Testing Non-DOM Features

Feature sniffing can be used on any JavaScript object: not just methods, and not just those methods that are part of the DOM. Commonly used examples are the offset properties ( offsetWidth , offsetHeight , offsetLeft and offsetTop ) of an element. These JavaScript properties are an extension to the DOM provided by all the major browsers. They return information on the size and position of an element in pixels. We can test whether those properties are defined on a given element's object as follows:

var foo = document.getElementById('foo');

if (typeof foo.offsetHeight != 'undefined') { ? ?
var fooHeight = foo.offsetHeight; ? ?
}

Here, we set fooHeight if, and only if, offsetHeight is supported on foo. This is a different type of check from the method we used before, though: isn't it possible simply to say, if (foo.offsetHeight) ? This isn't a good approach to use. If foo.offsetHeight is not defined, if (foo.offsetHeight) will not be true, just as we expect. However, the if statement will also fail if foo.offsetHeight does exist, but is equal to 0 (zero). This is possible because JavaScript treats zero as meaning false . Testing whether a given item is defined just got a little more complex (but only a little!).

If you are testing for the existence of function functionName , or method methodName (on an object obj ), use the function/method name without the brackets to do so:

if (functionName) { ... }
if (obj.methodName) { ... }

Likewise, if you're testing for a variable v , or for a DOM property prop of an object, you can often use the variable or the DOM attribute's property name directly:

if (v) { ... }
if (obj.prop) { ... }

But, watch out! If the variable or property contains numbers or strings (as does offsetHeight , for example) then use typeof , because a number might be 0 (zero), and a string might be the empty string "", both which also evaluate to false :

if (typeof v != 'undefined') { ... }
if (typeof obj.prop != 'undefined') { ... }

Sniffing at Work: scrollImage

Lots of Websites contain photo galleries: pages listing thumbnails of photographs that, when clicked on, display the photos at full size. An interesting enhancement to such a site might be to let the user see the full-size photo without having to click to load it. When the user mouses over the thumbnail, that thumbnail could become a "viewing area" in which a snippet of the full-sized image is shown. This technique is useful if your thumbnails aren't detailed enough to enable users to tell the difference between superficially similar images. It's especially handy if your thumbnails display something like a document, rather than a photo. Figure 4.1 shows the final effect:

Figure 4.1. The thumbnail display implemented by the scrollImage example.

We'll describe what's going on here in a moment. We'll review the code first, then see a demonstration before we get to the explanation.

Setting Up the Page

The HTML file for this technique is straightforward:

Example 4.1. scrollImage.html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd"> ? ?
<html> ? ?
<head> ? ?
<title>ScrollImage demonstration</title> ? ?
<script src="scrollImage.js" type="text/javascript"></script> ? ?
<style type="text/css"> ? ?
.scrollimage { ? ?
display: block; ? ?
float: left; ? ?
border: 1px solid black; ? ?
margin: 1em; ? ?
padding: 0; ? ?
} ? ?

.scrollimage:hover { ? ?
position: relative; ? ?
} ? ?

.scrollimage img { ? ?
border: none; ? ?
} ? ?

.scrollimage:hover img { ? ?
display: none; ? ?
} ? ?
</style> ? ?
</head> ? ?
<body> ? ?

<h1>Scanned documents</h1> ? ?

<p> ? ?
<a href="1.jpg" class="scrollimage" ? ?
mainx="563" mainy="823" thumbx="82" thumby="120" ? ?
style="background: url(1.jpg); width: 82px; ? ?
height: 120px;" ? ?
><img src="1-thumb.jpg"></a> ? ?

<a href="2.jpg" class="scrollimage" ? ?
mainx="563" mainy="777" thumbx="87" thumby="120" ? ?
style="background: url(2.jpg); width: 87px; ? ?
height: 120px;" ? ?
><img src="2-thumb.jpg"></a> ? ?

<a href="3.jpg" class="scrollimage" ? ?
mainx="567" mainy="823" thumbx="83" thumby="120" ? ?
style="background: url(3.jpg); width: 83px; ? ?
height: 120px;" ? ?
><img src="3-thumb.jpg"></a> ? ?

<a href="4.jpg" class="scrollimage" ? ?
mainx="558" mainy="806" thumbx="83" thumby="120" ? ?
style="background: url(4.jpg); width: 83px; ? ?
height: 120px;" ? ?
><img src="4-thumb.jpg"></a> ? ?

<a href="5.jpg" class="scrollimage" ? ?
mainx="434" mainy="467" thumbx="112" thumby="120" ? ?
style="background: url(5.jpg); width: 112px; ? ?
height: 120px;" ? ?
><img src="5-thumb.jpg"></a> ? ?
</p> ? ?

</body> ? ?
</html>/#pc#/ ? ?

The content of this page is fairly obvious. Notice how the image elements are hidden by CSS styles when the mouse moves over them. This page also includes - with the <script src="scrollImage.js" type="text/javascript"></script> line - this JavaScript file: ? ?

Example 4.2. scrollImage.js ? ?

/#pc#/// Based on findPos*, by ppk ? ?
// (http://www.quirksmode.org/js/findpos.html) ? ?
function findPosX(obj) { ? ?
var curLeft = 0; ? ?
if (obj.offsetParent) { ? ?
do { ? ?
curLeft += obj.offsetLeft; ? ?
} while (obj = obj.offsetParent); ? ?
} ? ?
else if (obj.x) { ? ?
curLeft += obj.x; ? ?
} ? ?
return curLeft; ? ?
} ? ?

function findPosY(obj) { ? ?
var curTop = 0; ? ?
if (obj.offsetParent) { ? ?
do { ? ?
curTop += obj.offsetTop; ? ?
} while (obj = obj.offsetParent); ? ?
} ? ?
else if (obj.y) { ? ?
curTop += obj.y; ? ?
} ? ?
return curTop; ? ?
} ? ?

// cross-browser event handling for IE5+, NS6+ and Mozilla/Gecko ? ?
// By Scott Andrew ? ?
function addEvent(obj, evType, fn, useCapture) { ? ?
if (obj.addEventListener) { ? ?
obj.addEventListener(evType, fn, useCapture); ? ?
return true; ? ?
} else if (obj.attachEvent) { ? ?
var r = obj.attachEvent('on' + evType, fn); ? ?
return r; ? ?
} else { ? ?
obj['on' + evType] = fn; ? ?
} ? ?
} ? ?

addEvent(window, 'load', scrollInit, false); ? ?

function scrollInit() { ? ?
if (!document.getElementsByTagName) ? ?
return; ? ?
var allLinks = document.getElementsByTagName('a'); ? ?
for (var i = 0; i < allLinks.length; i++) { ? ?
var link = allLinks[i]; ? ?
if ((' ' + link . className + ' ').indexOf(' scrollimage ') != ? ?
-1) { ? ?
addEvent(link, 'mousemove', moveListener, false); ? ?
} ? ?
} ? ?
} ? ?

function attVal(element, attName) { ? ?
return parseInt(element.getAttribute(attName)); ? ?
} ? ?

function moveListener(ev) { ? ?
var e = window.event ? window.event : ev; ? ?
var t = e.target ? e.target : e.srcElement; ? ?

var xPos = e.clientX - findPosX(t); ? ?
var yPos = e.clientY - findPosY(t); ? ?

if (t.nodeName.toLowerCase() == 'img') ? ?
t = t.parentNode; ? ?
if (t.nodeName.toLowerCase() == 'a') { ? ?

// scaleFactorY = (width(big) - width(small)) / width(small) ? ?
var scaleFactorY = ? ?
(attVal(t, 'mainy') - attVal(t, 'thumby')) / attVal(t, ? ?
'thumby'); ? ?
var scaleFactorX = ? ?
(attVal(t, 'mainx') - attVal(t, 'thumbx')) / attVal(t, ? ?
'thumbx'); ? ?

t.style.backgroundPosition = ? ?
(-parseInt(xPos * scaleFactorX)) + 'px ' + ? ?
(-parseInt(yPos * scaleFactorY)) + 'px'; ? ?
} ? ?
}

We'll explore (and fix!) this code shortly. Finally, the page also contains images: five at full-size, and five thumbnails. You can find them in the code archive for this book.

Demonstrating the DHTML Effect

Let's see how the page works. The HTML document shows five images as thumbnails; in this example, they're thumbnails of individual pages of a scanned-in document. Figure 4.2 shows the page content under normal circumstances.

Figure 4.2. Thumbnails of a document.

When we mouse-over a thumbnail image, though, the display of that thumbnail changes to show the actual image to which it's linked, as shown in Figure 4.3.

The thumbnail becomes a viewing area in which we can see a snippet of the full-size image. As the cursor moves over the third image, we see the content of the third image at full size through the viewing area. For a document thumbnail such as this, we can use the cursor to move around the document within the viewing area, so that we can read the content and see if it's the document we want. This technique can also be useful, as mentioned, in photo galleries containing images that look similar when displayed at thumbnail size.

Figure 4.3. Mousing over a thumbnail.

How the Code Works

Conceptually, the code works as follows: we set up the page so that every "scrollable" image is made up of an <a> tag of class scrollimage , which contains an <img> tag displaying the thumbnail. We apply the full-size image as the CSS background image of the <a> tag. Then, when the user mouses over the a element, we hide the img element entirely, allowing the a element's background image to show through. We then manipulate the position of that background image so that it moves in accordance with the cursor. (We're storing the dimensions of the larger image in custom attributes on the a element: mainx , mainy , thumbx , and thumby . This is a slightly suspect technique: it will prevent the HTML from validating, and should therefore be approached with caution. In this case, however, it is the easiest way to tie the required values to each of the a elements.)

This is all fairly advanced stuff, so we need to confirm that the running browser supports all the features we need in order to make it work. We start by making the script initialize on page load with the line:

Example 4.3. scrollImage.js (excerpt)

addEvent(window, 'load', scrollInit, false);/#pc#/

We saw the addEvent method in Chapter 3, Handling DOM Events , but, with what we've learned about feature detection, its workings should now be much clearer to you. First, we check for the existence of an addEventListener method on the passed object, to see if the user's browser supports the DOM Events model correctly: ? ?

Example 4.4. scrollImage.js (excerpt) ? ?

/#pc#/function addEvent(obj, evType, fn, useCapture) { ? ?
if (obj.addEventListener) { ? ?
obj.addEventListener(evType, fn, useCapture); ? ?
return true;

Failing that, we look for Internet Explorer's proprietary attachEvent method on the object.

Example 4.5. scrollImage.js (excerpt)

} else if (obj.attachEvent) { ? ?
var r = obj.attachEvent('on' + evType, fn); ? ?
return r;

Failing that , we attach the event listener directly to the element, as an event handler; this is required for IE5 on Macintosh.

Example 4.6. scrollImage.js (excerpt)

} else { ? ?
obj['on' + evType] = fn; ? ?
}

This procedure caters for all the ways by which we might attach an event listener, using feature sniffing to see which option is available.

The initialization function that sets up the scrolling effect, scrollInit , uses document.getElementsByTagName to find all the a elements in the document. Therefore, scrollInit checks for this method’s existence before proceeding:

Example 4.7. scrollImage.js (excerpt)

function scrollInit() {
if (!document.getElementsByTagName) ? ?
return;

If the user’s browser doesn’t support document .getElementsByTagName , then we return from the scrollInit function and don’t progress any further.

One extra trick in the feature sniffing code, as described in Chapter 3, Handling DOM Events , addresses the way in which we find the event object when we’re inside the moveListener event listener. As we know, the DOM Events specification mandates that an event object is passed to the event listener as an argument, whereas Internet Explorer makes the event object available as the global window.event. So, our code checks for the existence of window.event , and uses it as the event object if it exists; the code falls back to the passed-in argument if window.event is not present:

Example 4.8. scrollImage.js (excerpt)

function moveListener(ev) {
var e = window.event ? window.event : ev;

Next, we need to get the event’s target from that event object; the DOM specifies e.target , and Internet Explorer provides e.srcElement . Another feature-sniff gives us the appropriate value:

Example 4.9. scrollImage.js (excerpt)

var t = e.target ? e.target : e.srcElement;

This is a compressed, shorthand version of the code we saw in Chapter 3, Handling DOM Events .

The next step is for the code to get the position of the mouse inside the thumbnail image area. This is the code from the full listing above that is supposed to do this:

var xPos = e.clientX - findPosX(t); ? ?
var yPos = e.clientY - findPosY(t);

In theory, e.clientX and e.clientY give the x- and y-coordinates of the mouse within the browser window, respectively. By subtracting from these the x- and y-coordinates of the target element, we obtain the mouse’s position within that element.

Depending on your browser of choice, this might seem to work just fine at first glance. Peter-Paul Koch’s findPosX and findPosY functions make short work of getting the target element’s position. (For a complete description of how findPosX and findPosY work, visit Peter-Paul Koch’s page on the subject .) Unfortunately, the clientX and clientY properties of the event object are nowhere near as reliable.

clientX and clientY Problems

The code above is flawed: the event listener uses e.clientX and e.clientY to ascertain the position of the mouse.

But that’s not a flaw, is it? After all, it’s in the DOM specifications!

Well, it’s sort of a flaw – a flaw in the way browser manufacturers interpret the specification. Peter-Paul Koch studies this problem in great detail in his comprehensive article, Mission Impossible – Mouse Position . The problem occurs only when the page is scrolled (which was not the case with the above page). When a page is scrolled, the specification is rather vague on whether clientX and clientY are returned relative to the whole document, or to the window (the part of the document that is visible). Internet Explorer returns them relative to the window, as does Mozilla, but all of Opera, Konqueror, and iCab return them relative to the document. Netscape also provides pageX and pageY, which are mouse coordinates relative to the document. (Ironically enough, Internet Explorer may be the only browser which is fully compliant with the standard; the best reading of the specification is that clientX and clientY should be relative to the window.)

So, we need to use pageX and pageY if they exist, and clientX and clientY if they do not; if we’re in Internet Explorer, however, we have to add to clientX and clientY the amounts by which the page has been scrolled. But how do we know if we’re in Internet Explorer? We use browser detection.

Browser Detection You Can’t Avoid

That spluttering noise you can hear in the background is the crowd rightly pointing out that we consigned browser detection to the dustbin of history only a few pages back, and they’re not wrong. However, there are occasions when different browsers implement the same properties (in this case, clientX and clientY) in different ways and when there are no other objects available for sniffing that can us tell which of the different implementations is in use.

On such occasions, there is no alternative but to use the dreaded browser sniffing to work out what to do. The mouse position issue described here is almost the only such situation. The very thought that it might be necessary to use browser detection should make all right-thinking DHTML developers shudder with guilt, but, sadly, there’s nothing for it! We add the browser detection script to the code just before we call addEvent to set up our window load listener:

Example 4.10. scrollImage.js (excerpt)

var isIE = !window.opera && navigator.userAgent.indexOf('MSIE') !=
-1;

Note that, first, we check that window.opera is false or non-existent; Opera sets this variable to make it easy for scripts to detect that it is the browser in use (Opera also implements user-agent switching, so that, from a navigator.userAgent perspective, it can appear to be Internet Explorer). Once we’ve established that we’re not using Opera, we go on to look for "MSIE" in the user agent string; if this is present, Internet Explorer is the browser in use.

Our updated moveListener event listener now looks like this:

Example 4.11. scrollImage.js (excerpt)

Note that we check first for pageX and pageY (for Mozilla), then fall through to clientX and clientY. We handle Internet Explorer by checking the isIE variable; if it’s true , we add the document’s scroll amounts as required. We’re using the browser detect as little as possible; specifically, Netscape/Mozilla provide the pageX and pageY properties, and we look for them through feature sniffing, not by performing browser detection for Mozilla.

Calculating Screen Positions

The last section of our code has little to do with browser detects, but, having spent all this time to get the right X and Y coordinates, it makes sense to understand how to use them.

The last part of the moveListener function starts with a couple of if s, which ensure that we have in hand a reference to the <a> tag surrounding the thumbnail <img> of interest. No surprises there, so we grab the required DOM element:

Example 4.12. scrollImage.js (excerpt)

if (t.nodeName.toLowerCase() == 'img') ? ?
t = t.parentNode; ? ?
if (t.nodeName.toLowerCase() == 'a') {

Next, we have the first of two sets of calculations:

Example 4.13. scrollImage.js (excerpt)

// scaleFactorY = (width(big) - width(small)) / width(small) ? ?
var scaleFactorY = ? ?
(attVal(t, 'mainy') - attVal(t, 'thumby')) / attVal(t, ? ?
'thumby'); ? ?
var scaleFactorX = ? ?
(attVal(t, 'mainx') - attVal(t, 'thumbx')) / attVal(t, ? ?
'thumbx');

Code like this is liable to be specific to each DHTML effect you undertake, but the mind-bending you have to do to come up with the code is similar in all cases. Take a deep breath: here we go!

With the large background image showing through the viewing area, what should appear when the cursor is in the top-left corner of that viewing area? The top-left corner of the big image should be in the top-left corner of the viewing area: that’s straightforward. Now, what should appear when the cursor is located at the bottom-right corner of the viewing area? Should the bottom-right corner of the full-sized image be in the top-left corner of the viewing area? That’s what would happen if the big image were moved by its full size across the viewing area as the cursor was moved the full distance across the viewing area. Think about it carefully; you might like to try experimenting with two pieces of paper, one of which has a rectangular hole in it. The big image would eventually disappear off the top-left corner of the viewing area! If the background image were tiled (the default), additional copies of the image would be visible at this bottom-right corner – a very odd result.

We don’t want the image to move that far. If we move the cursor to the extreme bottom-right of the viewing area, we want the big image to move by almost its entire size – but not quite! We want the bottom-right corner of the big image to move only as far as the bottom-right corner of the viewing area, and not move any further towards the top-left.

Now, to make the big image move, we have to calculate a distance by which to move it. Take some example figures: suppose the big image is ten times the size of the thumbnail. Let’s suppose the image is 500 pixels on each side, and the thumbnail’s 50 pixels on each side. For every pixel by which the cursor moves, the big image should move 500/50: ten times as fast. So the "scale factor" is ten. But, wait a minute! If the cursor moves 50 pixels left, the big image will move 500 pixels left: right off the left edge of the viewing area. That’s too far. We want it to move at most 500 minus 50 pixels, so that it’s always "inside" the viewing area. Therefore, the real scale factor is (500 a€“ 50) / 50 = 9. The full-sized image should move nine times as fast as the cursor. That’s what the first set of calculations does, except that it calculates scale factors in both dimensions, since most images are rectangles, not squares.

Next, we want to move the big image. Here’s the second set of calculations:

Example 4.14. scrollImage.js (excerpt)

t.style.backgroundPosition = ? ?
(-parseInt(xPos * scaleFactorX)) + 'px ' + ? ?
(-parseInt(yPos * scaleFactorY)) + 'px';

Now, if (for example) we move the mouse from the top-left towards the bottom-right, we’re scanning diagonally across the viewing area. As we move, we want new areas of the big image to come into view. So the big image had better slide in the opposite direction to the mouse: up towards, and beyond, the top left. It’s like using a negative margin to bleed text to the left and top of a page. And that’s what we do by calculating negative pixel amounts.

This idea may seem back-to-front initially. Think of it as though you were shooting a scene for a movie. The camera (the thumbnail viewing area) is fixed into place, so it must be the scene at which the camera points that moves if there’s to be any panning effect. Alternately, imagine yourself looking out of the window of a moving train without turning your head. It’s the same effect again, provided the train goes backwards!

Summary

In this chapter, we’ve learned that browsers don’t always support all the DOM features we’d like, and discussed how feature sniffing helps us as DHTML developers to code defensively around this issue. Browser sniffing allows us to deliver dynamic features to browsers that can handle them and, at the same time, to avoid crashing or throwing errors in browsers that can’t. We looked at the old method, browser sniffing, and explained why it shouldn’t be used if at all possible. We then explored one occasion on which feature sniffing can’t provide everything we need, leaving us the old method as a last resort.

That’s it for this excerpt of DHTML Utopia: Modern Web Design Using JavaScript & DOM ! What’s next?

Download this chapter in PDF format , and you’ll have a copy you can refer to at any time.

Review the book’s table of contents to find out exactly what’s included.

Buy your own copy of the book now, right here at SitePoint.com.

We hope you enjoy DHTML Utopia: Modern Web Design Using JavaScript & DOM .

翻譯自: https://www.sitepoint.com/dhtml-utopia-modern-web-design/

dhtml

總結(jié)

以上是生活随笔為你收集整理的dhtml_DHTML乌托邦：使用JavaScript和DOM的现代Web设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。

上一篇： [SDOI2009][BZOJ 1226
下一篇：编程语言-什么是高级语言？