HTML5+CSS3網(wǎng)頁設(shè)計(jì)入門

TML5+CSS3網(wǎng)頁設(shè)

k計(jì)入門

目錄

第1章標(biāo)記簡史

1.1從IETF到W3C：HTML4的誕生過程

1.2XHTMLT：符合XML標(biāo)準(zhǔn)的HTML

1.3XHTML2：不被接受

1.4分裂：WHATWGTF

1.5從WebApps1.0至UHTML5

1.6再次聯(lián)手

1.7XHTML已被廢棄：XHTML的語法永存

1.8總結(jié)

第2章HTML5的設(shè)計(jì)

2.1設(shè)計(jì)原則

2.2切合現(xiàn)實(shí)

2.3錯誤處理

2.4DOCTYPE：形式更簡潔

2.5保持簡潔

2.6語法：以自己的方式進(jìn)行標(biāo)記

2.7我們不使用這種語言

2.8轉(zhuǎn)變（CH-CH變化）

2.9閃亮的新工具：lavaScriptAPI

第3章富媒體

3.1canvas

3.2音頻

3.3視頻

第4章WebForms2.0

4.1placeholder屬性

4.2autofocus屬性

4.3required屬性

4.4autocomplete屆T生

4.5datalist元素

4.6輸入類型

4.7展望未來

第5章語義

5.1擴(kuò)展性

5.2新元素

5.3結(jié)構(gòu)

5.4內(nèi)容模型

第6章開始使用HTML5

6.1樣式

6.2ARIA

6.3驗(yàn)證

64功能檢測

6.5選擇策略

6.6未來

作者簡介

CSS3網(wǎng)頁設(shè)計(jì)入門必讀

序

第1章CSS3應(yīng)用現(xiàn)狀

1.1不要閱讀規(guī)范

1.2人人都能用CSS3

1.3目前可用的CSS3核心屬性

1.4供應(yīng)商特定前綴

第2章理解CSS過渡

2.1主次顛倒

2.2什么是CSS過渡？

2.3簡單的示例

2.4時(shí)間函數(shù)

2.5延遲過渡

2.6速記過渡

2.7瀏覽器支持

2.8構(gòu)建完整的過渡(transition)堆棧

2.9過渡狀態(tài)

2.10過渡多個(gè)屬性

2.11過渡所有可能的屬性

2.12可過渡的CSS屬性

2.13為何不用JavaScript替代CSS3

2.14明智且認(rèn)真地應(yīng)用過渡

第3章CSS懸停效果

3.1案例研究

3.2驚奇和喜悅

3.3各個(gè)瀏覽器里的網(wǎng)站都需要完全相同的體驗(yàn)嗎

3.4操控月球

3.5使用透明度（opacity）制作簡單且靈活的懸停效果

3.6發(fā)布和制作懸停

第4章CSS變形

4.1縮放變形

4.2變形體驗(yàn)

4.3旋轉(zhuǎn)、傾斜和平移

4.4幫助支持內(nèi)容的不同變形

4.5對月亮應(yīng)用變形

4.6再次強(qiáng)調(diào)：明智且認(rèn)真地應(yīng)用變形

第5章多重背景

5.1視差滾動

5.2舊方法：附加標(biāo)記

5.3新方法：CSS3多重背景

5.4multiplebackground當(dāng)前的f更用'情7兄

第6章豐富表單

6.1標(biāo)記簡單的注冊表單

6.2為控件和標(biāo)簽添加樣式

6.3為輸入文本設(shè)計(jì)樣式

6.4應(yīng)用CSS3漸變

6.5純粹的CSS3按鈕

6.6其他瀏覽器的情況如何

6.7使用box-shadow創(chuàng)建:focus狀態(tài)

6.8應(yīng)用CSS動畫來豐富表單交互

6.9聚焦交互

第7章總結(jié)

7.1怎樣應(yīng)對不接受CSS3的客戶和老板

7.2展望未來

第1章標(biāo)記簡史

HTML是萬維網(wǎng)（WorldWideWeb）的統(tǒng)一語言。通過它所提供的標(biāo)簽，人類已經(jīng)

創(chuàng)建了各種各樣令人驚奇的超鏈接文檔網(wǎng)絡(luò)。從Amazon、eBay和Wikipedia,到個(gè)人博

客和貓咪主題網(wǎng)站，這些無一不是HTML的杰作。

HTML5是這門通用語言的最新版。自誕生之日起，這門語言一直在不停地發(fā)展。雖

然這次升級的變化之大史無前例，但HTML已經(jīng)不是第一次進(jìn)行更新?lián)Q代了。

在發(fā)明Web的同時(shí)，蒂莫西?約翰-伯納斯一李爵士創(chuàng)建了HTML（HyperText

MarkupLanguage,超文本標(biāo)記語言）。1991年,他撰寫了一篇名為“HTMLTags"的文檔,

在該文檔中，他推薦了將近20個(gè)用來編寫網(wǎng)頁的元素。

使用尖括號包圍文本這種形式的標(biāo)簽并不是蒂姆先生的首創(chuàng)。在此之前，SGML

（StandardGeneralizedMarkupLanguage,標(biāo)準(zhǔn)通用標(biāo)記語言）就已經(jīng)開始使用這種標(biāo)

簽了。蒂姆先生并沒有發(fā)明新的語言，而是利用已經(jīng)存在的技術(shù)一在HTML5的發(fā)展過程

也體現(xiàn)了這種傾向。

1.1從IETF到W3C：HTML4的誕生過程

實(shí)際上，根本不存在HTML1。最早的HTML官方規(guī)范是由IETF（Internet

EngineeringTaskForce,因特網(wǎng)工程任務(wù)組）發(fā)布的HTML2.0。這一規(guī)范中的許多特性

都是在已有實(shí)現(xiàn)的基礎(chǔ)上歸納總結(jié)出來的。例如，1994年居于市場領(lǐng)導(dǎo)地位的Mosaic

瀏覽器提供了＜img＞標(biāo)簽，開發(fā)人員可以通過該標(biāo)簽在自己的文檔中嵌入圖像。后來，

img元素就出現(xiàn)在了HTML2.0中。

繼IETF之后，W3C（WorldWideWebConsortium,萬維網(wǎng)聯(lián)盟）成為了HTML后

續(xù)標(biāo)準(zhǔn)的制定者，其官方網(wǎng)站為http:〃。20世紀(jì)90年代中期以后，W3C

對HTML進(jìn)行了幾次升級，直至1999年發(fā)布的HTML4.010

此時(shí)，HTML的發(fā)展走到了一個(gè)十字路口。

1.2XHTML1：符合XML標(biāo)準(zhǔn)的HTML

HTML4.01之后的修訂版為XHTML1.0。其中，X表示"eXtreme（極端）'當(dāng)時(shí)的

網(wǎng)頁開發(fā)人員在提到這個(gè)字母的時(shí)候，必須雙臂交叉，作出一個(gè)X的形狀來。

這只是個(gè)玩笑。實(shí)際上，X表示的是"extensible（可擴(kuò)展）另外，也沒有必要在

提到它時(shí)交叉雙臂。

XHTML1.0規(guī)范的內(nèi)容與HTML4.01完全相同。沒有添加任何新元素或新屬性。這

兩個(gè)規(guī)范唯一的差別就是對HTML語法作出了不同的規(guī)定。HTML為開發(fā)人員提供了很

大的自由度，他們可以按照自己的意愿去編寫元素和屬性，但XHTML卻要求開發(fā)人員遵

從XML規(guī)則。XML是W3C大多數(shù)技術(shù)規(guī)范的基礎(chǔ)，也是一種更為嚴(yán)格的標(biāo)記語言。

更加嚴(yán)格的語法規(guī)則并沒有什么壞處，反而可以促使開發(fā)人員按照統(tǒng)一的樣式來編寫

標(biāo)簽。此前的標(biāo)簽和屬性可以是大寫、小寫，或者任意大小寫字母的組合，而XHTML1.0

文檔則要求所有標(biāo)簽和屬性都必須為小寫。

XHTML1.0發(fā)布的時(shí)候恰逢瀏覽器普遍開始支持CSSo開發(fā)人員意識到了網(wǎng)頁標(biāo)準(zhǔn)的

出現(xiàn)，特別是在Web標(biāo)準(zhǔn)項(xiàng)目（TheWebStandardsProject）的倡導(dǎo)下，XHTML規(guī)定的

這種更為嚴(yán)格的語法被看成是編寫標(biāo)記的“最佳實(shí)踐”。

在此之后，W3c發(fā)布了XHTML1.1。

如果說XHTML1.0只不過是用XML重新表示的HTML,那么XHTML1.1才是真正且

純粹的XML。也就是說，不能將text/html的MIME類型提供給XHTML1.1文檔。但是,

如果開發(fā)人員以XML的MIMI類型來發(fā)布文檔，那么當(dāng)時(shí)世界上最流行的Web瀏覽器一

InternetExplorer—就無法呈現(xiàn)該文檔。

W3C似乎已經(jīng)開始與日常的網(wǎng)頁發(fā)布脫節(jié)了。

1.3XHTML2：不被接受

如果DustinHoffman在電影《TheGraduate》（華業(yè)生）中的角色是一名網(wǎng)頁設(shè)計(jì)

師，那么W3c只會對他說一個(gè)詞：XMLo

W3c在接管HTML的時(shí)候，HTML已經(jīng)發(fā)展到了第4版（version4）。然后他們又

著手開發(fā)XHTML2,其目的是將Web建立在XML之上。

雖然XHTML2的名字聽起來與XHTML1非常類似，但它們的差別卻非常之大。與

XHTML1不同，XHTML2與已有的網(wǎng)頁內(nèi)容都不兼容，甚至與以前版本的HTML也不兼

容。XHTML2的目的就是成為一門純粹的語言，也就是不與以前的規(guī)范建立任何關(guān)系。

但這卻是一場災(zāi)難。

1.4分裂：WHATWGTF

一股反抗勢力在W3c內(nèi)部逐步壯大。W3c熱衷于從理論角度構(gòu)建單純的標(biāo)準(zhǔn)，卻無

視網(wǎng)頁設(shè)計(jì)人員的需求。來自O(shè)pera、Apple和Mozilla的代表對這種傾向非常反感，他

們希望那些支持創(chuàng)建Web應(yīng)用的特性能夠得到更多的關(guān)注。

2004年的一次工作組會議成為了矛盾激化的導(dǎo)火索。伊恩??？松ó?dāng)時(shí)仍效力于

OperaSoftware）建議，應(yīng)以支持創(chuàng)建Web應(yīng)用為目標(biāo)來擴(kuò)展HTML,但這個(gè)提議被駁

回了。

于是，心懷不滿的反抗者們建立了自己的組織：WebHypertextApplication

TechnologyWorkingGroup（Web超文本應(yīng)用技術(shù)工作組），簡稱WHATWG。

1.5從WebApps1.0到］HTML5

從一開始，WHATWG的工作方式就與W3c截然不同。W3c采取基于表決的工作方

式：提出議題、討論議題、投票表決。WHATWG同樣會提出和討論議題，但哪些特性可

以被寫入規(guī)范最終由編輯決定。而這個(gè)編輯就是伊恩??？松?。

表面上看，W3c的流程更民主，也更公平。但實(shí)際上，政治博弈和內(nèi)部爭論經(jīng)常會

導(dǎo)致流程停滯不前。而在WHATWG中，任何人都可以自由地發(fā)表意見，但負(fù)責(zé)最后決議

的則只有編輯一個(gè)人，因此其工作效率明顯高很多。其實(shí)編輯也并非擁有絕對的權(quán)力：一

個(gè)僅由受邀人員組成的指導(dǎo)委員會可以質(zhì)疑編輯的偏執(zhí)做法。

最初，WHATWG的大部分工作被分為兩個(gè)規(guī)范：WebForm2.0和WebApps1.0。

這兩個(gè)規(guī)范都是在HTML的基礎(chǔ)上擴(kuò)展而來的。后來，這兩個(gè)規(guī)范又被合并到一起，同

時(shí)被簡單地稱為HTML5。

1.6再次聯(lián)手

在WHATWG開發(fā)HTML5期間，W3C繼續(xù)制定了XHTML2規(guī)范。如果說XHTML2

規(guī)范的制定速度很快，那是不準(zhǔn)確的。實(shí)際上，這個(gè)過程是十分緩慢的。

2006年10月，蒂姆先生發(fā)表了一篇博文，承認(rèn)將Web從HTML遷移到XML是行

不通的。幾個(gè)月后，W3c簽發(fā)了新委任狀，成立了一個(gè)HTML工作組。這個(gè)工作組并沒

有采取一切從頭開始的方式，而是明智地決定：應(yīng)該在WHATWG工作成果的基礎(chǔ)上開發(fā)

未來版本的HTML?

這樣，時(shí)斷時(shí)續(xù)的做法反而使情況變得令人困惑。W3C同時(shí)有兩個(gè)工作組，分別負(fù)

責(zé)制定不同的、互不兼容的標(biāo)記語言：*口丁乂12和口丁乂1.5（注意數(shù)字5前面有一個(gè)空

格）。與此同時(shí)，還有一個(gè)獨(dú)立的組織，即WHATWG,正在開發(fā)HTML5（沒有空格）

規(guī)范，而該規(guī)范將作為上述W3c中一個(gè)規(guī)范的基礎(chǔ)。

網(wǎng)頁設(shè)計(jì)師們會發(fā)現(xiàn)，搞清楚上述狀況比理解電影《記憶碎片》、《雷管》、甚至導(dǎo)

演大衛(wèi)?林奇的所有作品都要困難。

1.7XHTML已被廢棄：XHTML的語法永存

種種迷團(tuán)終于在2009年煙消云散。W3C宣布不再續(xù)頒XHTML2工作組的委任狀。

實(shí)際上，這種格式已經(jīng)被廢棄好幾年了。這次的宣布差不多可以看成是為它補(bǔ)發(fā)了一張死

亡證明。

奇怪的是，XHTML2并沒有平靜地逝去，不少興災(zāi)樂禍的人跳出來大放厥詞。XML

的反對者趁機(jī)奚落使用XHTML1的開發(fā)人員一甚至忽略了XHTML1和XHTML2幾乎沒

有任何共同點(diǎn)這一事實(shí)。

這時(shí)候，那些遵照XHTML1嚴(yán)格規(guī)則的開發(fā)人員又擔(dān)心起來，生怕HTML5又重新

開始支持過去的標(biāo)記。

其實(shí)，這樣擔(dān)心是多余的。雖然HTML5允許相對隨意的標(biāo)記，但它也支持嚴(yán)格的標(biāo)

記，到底選擇哪種風(fēng)格行事完全取決于使用人員。

1.8總結(jié)

切記，HTML5并不是一門憑空造出來的新語言。其標(biāo)記的變化都是革新性的而非革

命性的。無論開發(fā)人員正在使用哪個(gè)版本的HTML創(chuàng)建網(wǎng)站，他都可以說自己已經(jīng)在使

用HTML5了。

第2章HTML5的設(shè)計(jì)

法國大革命是極端的政治和社會變革時(shí)期。這種革命熱情也被傾注于對計(jì)時(shí)系統(tǒng)的改

革中。在一段時(shí)期內(nèi)，法蘭西共和國引入了十進(jìn)制計(jì)時(shí)制，即1天分為10小時(shí)，且1小

時(shí)分為100分鐘。該計(jì)時(shí)制的邏輯性和清晰性明顯優(yōu)于六十進(jìn)制的計(jì)時(shí)制。

但十進(jìn)制的計(jì)時(shí)制失敗了。沒有人使用這種計(jì)時(shí)制度。而XHTML2的命運(yùn)與之相似。

W3C再次證明了法國大革命的教訓(xùn)：改變現(xiàn)有的行為習(xí)慣是非常非常困難的。

2.1設(shè)計(jì)原則

為了避免過去所犯的錯誤，WHATWG起草了一系列設(shè)計(jì)原則以指導(dǎo)HTML5的開發(fā)。

其中一項(xiàng)主要原則是“支持已有內(nèi)容”。這意味著對于HTML5來說，并不存在創(chuàng)立的起始

時(shí)間。

XHTML2試圖廢棄之前的一切。而與之不同的是，HTML5建立在現(xiàn)有規(guī)范和實(shí)現(xiàn)的

基礎(chǔ)之上。HTML4.01的大部分內(nèi)容在HTML5中都得到了保留。

一些其他的設(shè)計(jì)原則，例如"不要做重復(fù)的工作”和“沿著足跡鋪路”的意思是，對于網(wǎng)

頁設(shè)計(jì)師來說，如果存在一種普遍的方法來完成某項(xiàng)任務(wù)，那么即使它不是最好的方法，

也應(yīng)該被編入HTML5中，也就是說"別去修理沒壞的東西"。

涉足過微格式(http:〃)的網(wǎng)頁設(shè)計(jì)師應(yīng)該十分熟悉這些設(shè)計(jì)原則。

HTML5社區(qū)具有同樣的務(wù)實(shí)方針以實(shí)現(xiàn)標(biāo)準(zhǔn)格式的統(tǒng)一，所以無需擔(dān)心理論問題。

這種態(tài)度體現(xiàn)在“最終用戶優(yōu)先”的設(shè)計(jì)原則中，該原則規(guī)定：在發(fā)生沖突時(shí)，最終用

戶優(yōu)先，其次是作者、實(shí)現(xiàn)者、標(biāo)準(zhǔn)制定者，最后才是理論上的完滿。

伊恩??？松呀?jīng)多次表示，瀏覽器廠商才是HTML5真正的仲裁者。如果瀏覽器供

應(yīng)商拒絕支持某項(xiàng)協(xié)議，那么在規(guī)范中添加該協(xié)議就變得沒有任何意義，因?yàn)檫@會使規(guī)范

不夠切合實(shí)際。根據(jù)最終用戶優(yōu)先的原則，網(wǎng)頁設(shè)計(jì)師的意見更具有意義。如果網(wǎng)頁設(shè)計(jì)

師拒絕使用規(guī)范的某些內(nèi)容，那么規(guī)范同樣不夠切合實(shí)際。

2.2切合現(xiàn)實(shí)

持續(xù)的內(nèi)部張力推動了HTML5的創(chuàng)立。一方面，規(guī)范需要足夠強(qiáng)大，從而有能力支

持創(chuàng)建網(wǎng)頁應(yīng)用程序，另一方面，雖然大多數(shù)現(xiàn)有內(nèi)容都處于完全混亂的狀態(tài)，但是

HTML5仍需要支持已有的內(nèi)容。如果HTML5的規(guī)范在某一個(gè)方向上偏離得太遠(yuǎn)，那么

它將重蹈XHTML2的覆轍。但是，如果它在另一個(gè)相反的方向上偏離得太遠(yuǎn)，那么它就

會認(rèn)為＜font＞標(biāo)簽和表單是萬能的，因?yàn)檫@兩者是大量網(wǎng)頁建立的基礎(chǔ)。

這是一種微妙的平衡，保持這種平衡需要務(wù)實(shí)且冷靜的方法。

2.3錯誤處理

HTML5不僅聲明了瀏覽器應(yīng)該如何處理規(guī)范格式的標(biāo)記，還首次規(guī)范了瀏覽器該如

何處理格式不規(guī)范的文件。

瀏覽器廠商曾不得不獨(dú)自研究如何處理錯誤。無論最流行的瀏覽器做出怎樣的嘗試，

該過程通常都會涉及逆向工程，這會耗費(fèi)瀏覽器廠商的時(shí)間。與其浪費(fèi)時(shí)間模仿競爭對手

處理有缺陷的標(biāo)記，倒不如嘗試實(shí)現(xiàn)新功能。

在HTML5中定義錯誤處理恐怕難以實(shí)現(xiàn)。雖然HTML5具有與HTML4.01完全相同

的元素和屬性，并且完全沒有添加新特性，但在2012年年底之前完成錯誤處理的定義仍

然是徒勞的。

網(wǎng)頁設(shè)計(jì)人員可能對錯誤處理不大感興趣，特別是在他們一開始就會編寫有效并且格

式規(guī)范的文件的情況下，但錯誤處理對于瀏覽器廠商來說卻非常重要。以往的標(biāo)記規(guī)范都

是為創(chuàng)作者編寫的，而HTML5卻是為創(chuàng)作者和實(shí)施者編寫的。網(wǎng)頁設(shè)計(jì)人員在細(xì)讀規(guī)范

時(shí)應(yīng)牢記這一點(diǎn)。這就解釋了為什么HTML5規(guī)范的內(nèi)容如此之多，同時(shí)也解釋了為什么

該規(guī)范含有一些通常為專家所保留的細(xì)節(jié)。

2.4DOCTYPE：形式更簡潔

文檔類型聲明(DocumentTypeDeclaration)簡稱為doctype,一直用于指定文檔所

編寫的標(biāo)記類型。

HTML4.01的doctype如下所示(》為自動換行標(biāo)記)：

<!DOCTYPEHTMLPUBLIC?

"-//W3C//DTDHTML4.01//EN"?

"/TR/html4/strict.dtd">

XHTML1.0的doctype如下所示：

<!DOCTYPEhtmlPUBLIC?

"-//W3C//DTDXHTML1.0Strict//EN"?

"/TR/xhtmll/DTD/xhtmll-strict.dtd">

這些doctype看起來并不易讀，但它們以其獨(dú)特的方式簡單地說明了："該文檔用

HTML4.01編寫"或"該文檔用XHTML1.0編寫

如果doctype聲稱"該文檔用HTML5編寫"，那么按道理其中應(yīng)該會出現(xiàn)數(shù)字5。但

事實(shí)并非如此。HTML5的doctype如下所示：

<!DOCTYPEhtml>

該doctype是如此之短，甚至可以讓人將其背誦下來。

這實(shí)在是太不可思議了！如果doctype中不含有版本號，那么該如何指定其他版本的

HTML呢？

第一次看到HTML5的doctype的時(shí)候，我認(rèn)為這是高度傲慢的結(jié)果。心想："難道

他們真相信這就是標(biāo)記規(guī)范的最終版了嗎？”

然而事實(shí)上，HTML5的doctype是非常務(wù)實(shí)的。由于HTML5需要支持現(xiàn)有內(nèi)容，

所以其doctype可以應(yīng)用于現(xiàn)有的HTML4.01文檔和XHTML1.0文檔。任何未來版本的

HTML也需要支持HTML5中的現(xiàn)有內(nèi)容，因此應(yīng)用版本號來標(biāo)記文檔的觀念是有缺陷的。

事實(shí)上，doctype并不那么重要。假設(shè)需要為一個(gè)文檔提供HTML4.01的doctype。

如果該文檔中包含來自另一個(gè)規(guī)范的元素，如HTML3.2或HTML5,那么瀏覽器將仍然

呈現(xiàn)該文檔的這一部分。這是因?yàn)闉g覽器支持的是特性，而非doctype。

起初，文檔類型聲明(DocumentTypeDeclaration)是為驗(yàn)證器而非為瀏覽器而設(shè)計(jì)

的。瀏覽器僅在"doctype轉(zhuǎn)換"的情況下才會關(guān)注doctype—"doctype轉(zhuǎn)換"(doctypy

switching)是一個(gè)聰明的小黑客，它根據(jù)是否存在合適的doctype來轉(zhuǎn)換顯示模式，即

怪異模式(quirksmode)或標(biāo)準(zhǔn)模式(standardmode)。

為了確保瀏覽器以標(biāo)準(zhǔn)模式顯示，至少需要HTML5的doctype。事實(shí)上，這是包含

doctype的唯一原因。不用HTML5的doctype編寫的HTML文檔仍然是有效的HTML5。

2.5保持簡潔

HTML5中簡化的不僅僅是doctypeo

如果想要指定一個(gè)標(biāo)記文檔的字符編碼，那么最好的方法就是確保服務(wù)器發(fā)送了正確

的Content-Type文件頭(header)。如果想要雙倍保險(xiǎn)，那么也可以使標(biāo)簽來

指定字符集。<meta>是一個(gè)用HTML4.01編寫的文件聲明：

<metahttp-equiv="Content-Type"content="text/html;?

charset=UTF-8">

下面的示例實(shí)現(xiàn)了與前一示例在HTML5中所實(shí)現(xiàn)的相同功能，但其實(shí)現(xiàn)方式更加令

人印象深刻：

<metacharset="UTF-8">

這種簡化了字符編碼的doctype包含了需要瀏覽器編譯的最少字符數(shù)。

另一處可以縮減字符數(shù)量的地方是〈script〉標(biāo)簽。常見的做法是為script元素添加

type屬性，屬性值為"text/javascript"：

<scripttype="text/javascript"src="file.js"><script>

瀏覽器并不需要該屬性。它們假定該腳本已用JavaScript編寫。JavaScript是最流行

的網(wǎng)頁腳本語言（實(shí)際上，JavaScript也是唯一的一種網(wǎng)絡(luò)腳本語言）：

<scriptsrc="file.js,,><script>

同樣，不需要在每次鏈接到CSS文件時(shí)都指定一個(gè)值為“text/CSS”的type屬性：

<linkrel="stylesheet“type="text/cssnhref=nfile.cssn>

只需簡單地寫為：

<linkrel=nstylesheetHhref=Hfile.css,,>

2.6語法：以自己的方式進(jìn)行標(biāo)記

一些編程語言，如Python,以其特殊的方式編寫說明。使用空格來縮進(jìn)代碼是強(qiáng)制

性的，空格很重要。而其他編程語言，如JavaScript,卻不在格式方面作任何要求，每一

行開頭是否空格并不那么重要。

如果與一些程序員同處一室并說出“重要的空格”之類的話，那么就會導(dǎo)致一整晚不斷

升溫的激烈辯論。

關(guān)于空格重要性的辯論核心存在一個(gè)基本的哲學(xué)問題：匯編語言應(yīng)該保持特定的匯編

風(fēng)格，還是編寫者可以按自己喜歡的風(fēng)格編寫？

標(biāo)記并不需要空格。如果想要在每次嵌套元素時(shí)都添加新的一行和縮進(jìn)，則需要添加

空格，但瀏覽器和校驗(yàn)器并不需要空格。這并不意味著標(biāo)記對所有情況都適用。有些種類

的標(biāo)記遵循更為嚴(yán)格的編寫風(fēng)格。

在XHTML1.0之前，使用大寫還是小寫來編寫標(biāo)簽并不重要。是否引用屬性也同樣

不那么重要。甚至對于某些元素來說，是否包含結(jié)束標(biāo)記都不會造成任何影響。

XHTML1.0強(qiáng)制執(zhí)行XML的語法：所有標(biāo)簽都必須為小寫，所有屬性都必須加引號,

所有元素都必須包含有結(jié)束標(biāo)記。對于獨(dú)立元素的特殊情況，例如br,以標(biāo)記結(jié)束替換

為以斜線<br/>結(jié)束。

如果使用HTML5,那么任何格式的命令都可以，無論是大寫、小寫、帶引號的、不

帶引號的、帶有結(jié)束符號的和不帶有結(jié)束符號的，使用哪種格式完全取決于程序員。

多年來，我一直在使用XHTML1.0的doctype。這是因?yàn)槲蚁矚g按照一種特定的樣式

編寫程序，從而也比較喜歡W3c驗(yàn)證對固定樣式的強(qiáng)制要求?，F(xiàn)在，我正在使用的是

HTML5,所以執(zhí)行哪種編寫樣式可以由自己決定。

我可以理解為什么有些人不喜歡HTML5語法的隨意性，因?yàn)檫@似乎是從最佳范例向

后的退步。有些人甚至?xí)f，HTML5對語法的寬松限制會導(dǎo)致不良標(biāo)記。雖然我并不這

樣認(rèn)為，但可以理解為什么這會成為一個(gè)備受關(guān)注的問題。因?yàn)檫@就好像是一種強(qiáng)制使用

空格的匯編語言突然在編程原則上變得寬容起來。

就個(gè)人而言，我可以接受HTML5語法的隨意性。但與此同時(shí)，我也強(qiáng)迫自己使用個(gè)

人青睞的編寫風(fēng)格。不過，我更希望見到更多的、可以以一種特定風(fēng)格測試標(biāo)記的工具。

在編程界，這些工具被稱為lint工具，即標(biāo)記可疑編碼范例的程序。驗(yàn)證器檢查的是

doctype,而用于標(biāo)記的lint工具卻與之不同；這兩者若可以結(jié)合為一種精益且介于兩者

之間的lint驗(yàn)證設(shè)備，那將會更好。

完成這樣設(shè)備的網(wǎng)頁設(shè)計(jì)師將會獲得來自世界各地的人們永久的尊重和敬佩。

2.7我們不使用這種語言

對于舊版本的HTML,從規(guī)范中移除先前存在的元素或?qū)傩缘倪^程被稱為廢棄。網(wǎng)頁

設(shè)計(jì)師不應(yīng)該使用、回顧甚至提及已廢棄的元素。

HTML5中不含有被廢棄的元素或?qū)傩?，但卻有大量過時(shí)的元素和屬性。

"過時(shí)"與"廢棄”在含義上有著微妙的區(qū)別。

由于HTML5的目的是向后兼容已有內(nèi)容，因此其規(guī)范必須承認(rèn)先前存在的元素，即

使這些元素已不包含在HTML5中。這將使情況變得略顯混亂，因?yàn)槠湟?guī)范還聲稱“編寫

人員請不要使用該元素”以及"瀏覽器應(yīng)該以此方式呈現(xiàn)該元素"。如果一個(gè)元素被廢棄，

那么它不應(yīng)在規(guī)范中被提到；但是由于該元素是過時(shí)的，為了照顧瀏覽器，它也被包含進(jìn)

來了。

除非正在開發(fā)一款瀏覽器，否則可以用對待廢棄元素和屬性的方式來對待過時(shí)的元素

和屬性，即不要在網(wǎng)頁中使用它們。

如果堅(jiān)持使用過時(shí)的元素或?qū)傩?，那么文件將變得“不符合要求”。瀏覽器將執(zhí)行一切

行得通的程序，但其他網(wǎng)站可能會對此表示不滿。

過時(shí)的元素

frame、frameset和noframes元素都已經(jīng)過時(shí)了。沒有人會懷念它們。acronym元

素也已經(jīng)過時(shí)了，因此導(dǎo)致了多年的討論，這些時(shí)間本可以被用在更有意義的事情上。不

要為acronym元素感到惋惜，使用abbr元素來代替它就可以了。首字母縮寫(acronym)

和縮寫(abbreviation)的確有所不同一首字母縮寫作為一個(gè)詞發(fā)音，例如NATO和

SCUBA,但請記住，所有的首字母縮寫都屬于縮寫，但并不是所有的縮寫都是首字母縮寫。

HTML5中的顯示元素，如font、big>center和strike都已經(jīng)過時(shí)了。實(shí)際上，它

們在多年前就已經(jīng)過時(shí)了。而使用CSS屬性，如font-size和text-align,則更容易獲得相

同的顯示效果。同樣，顯示元素的屬性，如bgcolor、cellspacing>cellpadding和valign

也都已經(jīng)過時(shí)了，使用CSS來代替這些屬性就可以了。

并非所有的顯示元素都已經(jīng)過時(shí)，它們中的一些元素經(jīng)過修改，已經(jīng)被重新利用起來。

2.8轉(zhuǎn)變（CH-CH變化）

元素big已經(jīng)過時(shí)了，但元素small卻還沒有。通過重新定義small的含義，這種顯

著的矛盾已經(jīng)得到解決。small的含義不再是其字面意義，即"在小號字體下進(jìn)行顯示"。

相反，其語義值變?yōu)榉尚g(shù)語、條款或附屬細(xì)則以小號字體顯示。

當(dāng)然，十有八九，開發(fā)人員會以小號字體顯示附屬細(xì)則，但重點(diǎn)是該元素的字面意義

已被取代。

元素b曾表示“用粗體顯示"?，F(xiàn)在，它被用來將一些文本“偏離正常的樣式而不具有

任何額外的重要性"。如果文本具有額外的重要性，那么使用該元素則更為合適。

元素i也不再意味著"傾斜"。它表示文本中“另一種的語氣或情緒”。同樣，該元素也

不表達(dá)任何重要性或重點(diǎn)。如果需要強(qiáng)調(diào)，則要使用em元素。

這些變化聽起來可能像是文字游戲。它們的確是文字游戲，但它們也有利于增強(qiáng)

HTML5的設(shè)備獨(dú)立性。如果仔細(xì)考慮"加粗"和"傾斜"，那么它們僅在視覺媒介（如屏幕或

頁面）中才能解釋得通。通過消除這些元素定義中的視覺偏差，HTML5的規(guī)范可與非可

視化用戶代理（如屏幕閱讀器）保持相關(guān)。這樣做可以避免設(shè)計(jì)師的思維被禁錮在視覺顯

示環(huán)境之內(nèi)。

2.8.1cite元素

HTML5對cite元素進(jìn)行了重新定義。cite元素原來表示的是“對其他參考資料的引

用“，但它現(xiàn)在的意思是"一部作品的標(biāo)題"。通常，被引用的參考為作品的標(biāo)題，例如一

本書或一部電影，但其根源很可能是一個(gè)人。在HTML5之前，可以使用cite來標(biāo)記這個(gè)

人的名字。但現(xiàn)在，這種做法被明令禁止一關(guān)于向后兼容性僅僅討論這么多。

對于這種修正的理由是：瀏覽器將＜cite＞標(biāo)簽之間的文本格式更改為斜體；作品的標(biāo)

題通常是斜體的；人名通常不是斜體。因此，cite元素不應(yīng)該被用于標(biāo)記人名。

但這是完全錯誤的。我贊成HTML5向?yàn)g覽器學(xué)習(xí)，但這種情況屬于主次顛倒。

幸運(yùn)的是，驗(yàn)證器無法分辨起始＜cite＞標(biāo)簽和結(jié)束＜/cite＞標(biāo)簽之間的文本是否是指

向人的，所以沒有什么能阻止網(wǎng)頁設(shè)計(jì)師用一種合理的、向下兼容的方式來使用cite元

素。

2.8.2增強(qiáng)型a元素

先前已有元素的變化僅僅是創(chuàng)造性的文字游戲，但HTML5對一個(gè)元素進(jìn)行了更為有

效的改造。

毫無疑問，a元素是HTML中最重要的元素。該元素將文本轉(zhuǎn)換成超文本，相當(dāng)于萬

維網(wǎng)的結(jié)締組織。

a元素是一個(gè)內(nèi)嵌元素。如果想要將一個(gè)標(biāo)題或一個(gè)段落轉(zhuǎn)化為超鏈接，則需使用多

個(gè)a元素：

<h2><ahref="/about">Aboutme</a></h2><h2><ahref="/about">About

me</a></h2>

<p><ahref="/about">Findoutwhatmakesmetick.</a><p>

在HTML5中，可以將多個(gè)元素封裝在一個(gè)a元素中：

<ahref="/about">

<h2>Aboutme</h2>

<p>Findoutwhatmakesmetick.</p>

</a>

唯一需要注意的是，不可以將一個(gè)a元素嵌套在另一個(gè)a元素中。

將多個(gè)元素包裝在一個(gè)元素中，這看起來似乎是一個(gè)巨大的變化。而且，要想支持這

種新的鏈接模式，大多數(shù)瀏覽器并不需要做很多工作。雖然這種標(biāo)記直到現(xiàn)在才成為合法

的，但大多數(shù)瀏覽器已經(jīng)支持了這種新的模式。

這似乎有些違背常理：瀏覽器應(yīng)該理所當(dāng)然地執(zhí)行已有的規(guī)范嗎？事實(shí)上正相反，是

最新的規(guī)范正在記錄瀏覽器所執(zhí)行的操作。

2.9閃亮的新工具：lavaScriptAPI

如果想要獲取關(guān)于CSS的文檔，需要查閱CSS規(guī)范。如果尋找的是有關(guān)標(biāo)記的文檔,

需要查閱HTML規(guī)范。但是，哪里可以查閱JavaScriptAPI的文檔，例如

document.write、innerHTML和window.hitory?JavaScript規(guī)范所涉及的全部是編程語

言，因此無法獲得任何與瀏覽器API有關(guān)的內(nèi)容。

到現(xiàn)在為止，瀏覽器一直獨(dú)立創(chuàng)建和執(zhí)行JavaScriptAPI并相互借鑒。HTML5對這

些API的記錄是一勞永逸的，因?yàn)檫@可以確保較好的兼容性。

在標(biāo)記規(guī)范中包含JavaScript規(guī)范聽起來可能有些奇怪，但要記住，HTML5是由

WebApps1.0發(fā)展而來的。JavaScript是制作Web應(yīng)用過程中不可缺少的一部分。

HTML5規(guī)范中的所有章節(jié)都致力于創(chuàng)建Web應(yīng)用的新API,其中包含一個(gè)Undo-

Manager一一它使得瀏覽器能夠跟蹤文檔變更。該規(guī)范中有一節(jié)介紹了如何使用緩存清單

來創(chuàng)建離線Web應(yīng)用。另外，該規(guī)范對拖放功能也進(jìn)行了詳細(xì)描述。

與往常一樣，如果存在已有的實(shí)現(xiàn)，那么規(guī)范將在其基礎(chǔ)上建立，而非將一切推倒重

來。微軟的IE瀏覽器在很多年前就已經(jīng)包含了拖放API,這也是HTML5拖放的基礎(chǔ)。遺

憾的是，微軟的API是有問題的。如果以前的基礎(chǔ)并不適用，那么重新開始也不見得是

壞主意。

HTML5中的API十分強(qiáng)大。它們完全超出了我的能力范疇，所以我將這些內(nèi)容留給

更優(yōu)秀的開發(fā)人員來編寫。這些API值得用一本單獨(dú)的書來介紹。

與此同時(shí)，對于網(wǎng)頁設(shè)計(jì)師來說，HTML5中仍存在許多新鮮事物。這些內(nèi)容將在下

一章進(jìn)行說明。

第3章富媒體

網(wǎng)絡(luò)的歷史伴隨著技術(shù)革新。img元素是HTML最早的擴(kuò)展之一，它從根本上改變

了網(wǎng)頁。隨后，JavaScript的引入使網(wǎng)頁環(huán)境變得更具活力。后來，Ajax的發(fā)展使得網(wǎng)頁

成為成熟應(yīng)用的一個(gè)可行選擇。

Web標(biāo)準(zhǔn)已經(jīng)發(fā)展得如此先進(jìn)，以至于現(xiàn)在（幾乎）可以使用HTML、CSS和

JavaScript來構(gòu)建任何事物。

Web標(biāo)準(zhǔn)中存在一些缺陷。如果想要發(fā)布文字和圖像，只需使用HTML和CSS。但

如果想要發(fā)布音頻或視頻，則需要使用插件技術(shù)，如Flash或Silverlight。

“插件”是涵蓋這些技術(shù)的準(zhǔn)確術(shù)語，它們用來填補(bǔ)網(wǎng)絡(luò)的空缺。插件使在線獲取游戲、

電影和音樂的過程變得相對容易。但這些技術(shù)都不是開放的。它們并不是由社區(qū)創(chuàng)建的，

而是由個(gè)體公司所掌控的。

Flash是一種功能強(qiáng)大的技術(shù)，但有時(shí)使用它卻像是一種不公平交易。通過Flash,

用戶可以在網(wǎng)絡(luò)上發(fā)布富媒體，但這也令用戶失去了一些獨(dú)立性。

HTML5正在填補(bǔ)這個(gè)缺陷。因此，它直接與Flash和Silverlight等專有技術(shù)相競爭。

但使用HTML5的富媒體并不需要插件元素；相反，它們是瀏覽器自帶的。

3.1canvas

當(dāng)Mosaic瀏覽器具備將圖像嵌入網(wǎng)頁的能力時(shí)，它為網(wǎng)絡(luò)帶來巨大的沖擊。但自此,

圖像一直是靜態(tài)的。用戶可以創(chuàng)建GIF動畫，使用JavaScript更新圖像的樣式，以及在服

務(wù)器上動態(tài)生成圖像。而一旦圖像被提供給瀏覽器，其內(nèi)容就不能更新了。

而canvas元素可以作為創(chuàng)建動態(tài)圖像的環(huán)境。

該元素本身十分簡單。需要在起始標(biāo)簽中指定的僅僅是尺寸：

<canvasid="my-first-canvas"width="360"height="240”>

</canvas>

如果將所有內(nèi)容都置于開始和結(jié)束標(biāo)簽之間，那么只有不支持canvas的瀏覽器才能

看到它（如圖3.1所示）：

<canvasid="my-first-canvas"width="360"height="240"><p>Nocanvas

support?Haveanold-fashionedimage?instead:</p>

<imgsrc="puppy.jpg"alt="acutepuppy">

</canvas>

不支持canvas?試試?yán)鲜降膱D像。

圖3.1不支持canvas的用戶看到的是一幅可愛小狗的圖像。

所有困難的工作都由JavaScript完成。首先需要引用canvas元素及其上下文context。

這里的"context”僅表示一個(gè)API?，F(xiàn)在，唯一的上下文是二維的：

varcanvas=document.getElementByld('my-first-canvas');

varcontext=canvas.getContext('2d');

現(xiàn)在就可以開始在canvas元素的二維表面上進(jìn)行繪制了。該過程使用存檔在HTML5

規(guī)范中的API。w

2DAPI提供了許多與圖像處理程序(如Illustrator)相同的工具：填充、漸變、陰影、

形狀和貝塞爾曲線。不同的是，2DAPI并不使用圖形用戶界面(GraphicalUserInterface,

GUI),開發(fā)人員必須指定所有使用JavaScript的事物。

使用架構(gòu)：代碼繪圖

下面的示例顯示了如何將筆觸顏色指定為紅色：

context.strokeStyle='#990000，;隨后繪制的任何事物都會具有紅色的輪廓。例如，如

果想要繪制一個(gè)矩形，可以使用以下語句：

strokeRect(left,top,width,height)如果想要繪制一個(gè)長為100像素、寬為50像素

的矩形，并且使其距canvas元素左邊界的距離為20像素而與頂部的距離為30像素(如

圖3.2所示)可以使用以下語句：

contextstrokeRect(20,30,100,50);

圖3.2使用canvas繪制的一個(gè)矩形。

這只是一個(gè)十分簡單的例子。2DAPI還提供了許多其他的類函數(shù)，如fillStyle、

fillRect、lineWidth和shadowColor等。

從理論上講，可以在如Illustrator之類的程序中創(chuàng)建的圖像都可以在canvas元素中

創(chuàng)建。但事實(shí)上，這樣做不僅十分費(fèi)力，還可能會導(dǎo)致過長的JavaScript。此外，這也不

是canvas的真正用途。

3.1.1canvas有何優(yōu)勢

使用JavaScript和canvas來創(chuàng)建動態(tài)圖像都十分不錯，那么，使用canvas有什么意

義呢？

canvas的真正優(yōu)勢是，其內(nèi)容可以隨時(shí)更新，從而根據(jù)用戶操作繪制新的內(nèi)容。這

種響應(yīng)用戶觸發(fā)事件的能力使得它可以創(chuàng)建無需插件技術(shù)(如Flash)的工具和游戲。

Mozilla實(shí)驗(yàn)室曾首次展示了一個(gè)體現(xiàn)canvas能力的經(jīng)典范例。Bespin應(yīng)用程序

()是一個(gè)在瀏覽器中運(yùn)行代碼的編輯器，如圖3,3所示。

該應(yīng)用的功能十分強(qiáng)大且令人印象深刻。同時(shí)，它也說明了在哪些方面不該使用

canvaso

?▲；AI?(}hnpf//btipinrncilHU.<Qm/fdiu>f.tnink?).<55

BeSpIn>S*npleProtedZztxl>?Q0AAA

^IcometoBesptnl

Afewnetpfultips:

?TojunpDfQthecoMioodUneandtheeditor,singlyMtCtrl-J

?1oturnof\trletl柳d。,wHlc八thoiyoucan'tclickdny^ntreintbc

Ch^ckout:

?hAQ：nttp%://wtkR.8ml口.crg/Lab、/Hi;%pin//AQ

?Ourtmttalonnouncement:httpV/laos.woitlla.co(V?W9/92/intr<xiuctng-besptn

圖3.3使用canvas建立的Bespin應(yīng)用程序。

3.1.2被拒絕的訪問

本質(zhì)上，代碼編輯器處理的是文本。Bespin代碼編輯器處理canvas元素中的文本一

除非這些文本并不是真正意義上的文本，而是一系列類似文本的圖形。

網(wǎng)絡(luò)上的所有文檔都可以用文檔對象模型(DocumentObjectModel,DOM)來描述。

該DOM具有許多不同的結(jié)點(diǎn)，其中最重要的就是元素節(jié)點(diǎn)、文本節(jié)點(diǎn)和屬性。這三個(gè)構(gòu)

建模塊足以組合任何文檔。而canvas元素不具有DOM。在canvas內(nèi)繪制的內(nèi)容不能表

示為一棵樹的節(jié)點(diǎn)。

為了解讀文檔，屏幕閱讀器及其他輔助技術(shù)依賴于對DOM的訪問。如果沒有DOM,

則不能進(jìn)行訪問。

canvas的可訪問性是HTML5的一個(gè)大問題。幸運(yùn)的是，一些非常聰明的開發(fā)人員組

成了一個(gè)特別小組,找出了解決方案(http://bkaprt.eom/html5/2)(.⑵

canvas的可訪問性是一個(gè)重大的問題，我不希望任何被提出的解決方案是倉促決定

的。與此同時(shí)，也不希望canvas影響HTML5規(guī)范的其他方面。

3.1.3聰明的canvas

如果可訪問性的問題得不到解決，那么對于網(wǎng)頁設(shè)計(jì)師來說，似乎canvas就像一塊

禁地。但事實(shí)卻并非如此。

每次使用網(wǎng)站上的JavaScript,我都將其作為增強(qiáng)。沒有JavaScript的訪問者仍然可

以訪問所有內(nèi)容，但其動態(tài)體驗(yàn)可能遠(yuǎn)不如支持JavaScript的環(huán)境。這種被稱為

UnobtrusiveJavascript的多層次方法，也可應(yīng)用于canvas。該方法不是用canvas來創(chuàng)建

內(nèi)容，而是用它來回收已有的內(nèi)容。

假設(shè)你有一個(gè)填有數(shù)據(jù)的表單，你可能希望用圖形來說明數(shù)據(jù)的趨勢。如果這些數(shù)據(jù)

是靜態(tài)的，則可以生成一張圖表，例如使用GoogleChartAPI。如果這些數(shù)據(jù)是可編輯的,

則可以將它們進(jìn)行更新以響應(yīng)用戶觸發(fā)事件，從而使canvas成為有助于生成變化圖表的

優(yōu)良工具。最重要的是，canvas元素中所顯示的內(nèi)容在已有的table元素中是可訪問的。

FilamentGroup中的一些工程師已經(jīng)為上述情況整合了一個(gè)jQuery插件，如圖3.4

所示；HTML5http://bkaprt.eom/html/3）。ui

圖3.4通過canvas,使用用戶輸入的數(shù)據(jù)生成的圖表。

還有另外一種選擇。canvas并不是唯一可以生成動態(tài)圖像的API。SVG（Scalable

VectorGraphics,可縮放矢量圖形）是一種XML格式，它可以將相同種類的形狀描述為

canvaso由于XML是一種基于文本的數(shù)據(jù)格式，因此在理論上，SVG的內(nèi)容也可以通過

屏幕閱讀器獲取。

實(shí)際上，SVG并不像canvas那樣吸引開發(fā)人員。雖然canvas是比較新的產(chǎn)品，但瀏

覽器已經(jīng)對它有不錯的支持。Safari>Firefox>Opera和Chrome都支持canvas,甚至還

存在一個(gè)可以為1E瀏覽器添加canvas支持的JavaScript庫。⑷

由于存在“沿著足跡鋪路"和"不要做重復(fù)的工作”這樣的原則，所以WHATWG在SVG

已經(jīng)存在的情況下主張?jiān)贖TML5中添加canvas看起來可能有些奇怪。通常，HTML5的

規(guī)范只是記錄瀏覽器的操作。canvas元素并不是為HTML5設(shè)計(jì)的，而是由蘋果公司創(chuàng)建

并在Safari中實(shí)現(xiàn)的。其他瀏覽器廠商十分欣賞蘋果公司所做的這項(xiàng)工作，并對其進(jìn)行

了效仿。

這看似雜亂無章，但卻往往是Web標(biāo)準(zhǔn)的起源。例如，在20世紀(jì)末，微軟為

InternetExplorer5創(chuàng)建了XMLHttpRequest對象。十年后，所有的瀏覽器都支持了該特

性。

在瀏覽器優(yōu)勝劣汰的環(huán)境下，canvas得到了廣泛傳播。如果能夠調(diào)整其可訪問性，

那么canvas就會得以生存。

3.2音頻

我平生建立的第一個(gè)網(wǎng)站展示的是自己的樂隊(duì)，并且希望該網(wǎng)站的訪問者能夠聽到樂

隊(duì)的歌曲。這促使我對多種媒體格式和媒體播放器進(jìn)行了研究：QuickTime.Windows

MediaPlayer和RealAudiOo我在考慮相對市場份額和跨平臺兼容性方面花費(fèi)了相當(dāng)多的

時(shí)間。

一開始，MP3格式憑借其普遍的存在擊敗了其他格式。但是，若要為訪問者提供一

個(gè)試聽音頻的簡單方法仍然需要專有的技術(shù)。在這方面，F(xiàn)lash播放器獲得了勝利。

現(xiàn)在，HTML5成為了新的冠軍。

將音頻文件嵌入HTML5文檔是十分簡單的：

<audiosrc="witchitalineman.mp3">

</audio>

但是，這有點(diǎn)過于簡單了。你可能希望更具體地了解audio應(yīng)該做些什么。

假設(shè)有一個(gè)邪惡的混蛋，他憎恨網(wǎng)絡(luò)以及所有使用網(wǎng)絡(luò)的人。雖然我們覺得在網(wǎng)頁中

嵌入自動播放的音頻文件是相當(dāng)粗魯和愚蠢的，但此人可能對此并不在乎。autoplay屬

性正好可以實(shí)現(xiàn)這類惡毒的野心：

<audiosrc="witchitalineman.mp3"autoplay>

</audio>

如果有人曾經(jīng)以這種方式使用autoplay屬性，那么我一定會把他抓住。

需要注意的是，autoplay沒有屬性值。這被稱為布爾屬性，該屬性是以數(shù)學(xué)家喬

治?布爾(GeorgeBoole)命名的。

計(jì)算機(jī)邏輯完全基于布爾邏輯：電流不是處于流動狀態(tài)就是處于非流動狀態(tài)；一個(gè)二

進(jìn)制值不是1就是0；計(jì)算結(jié)果不是真就是假。

不要混淆布爾值和布爾屬性?？梢哉J(rèn)為一個(gè)布爾屬性的值為"true”或"false"。但事實(shí)

上，這種屬性在本質(zhì)上是布爾型的一一無論該屬性是否被包含。即使為該屬性賦值，也不

會有任何效果。輸入autoplay="false"或autoplay="nothanks"與輸入autoplay的效果是

一樣的。

如果使用的是XHTML語法，則可以編寫autoplay="autoplay"。

如果自動播放的音頻文件還不夠惡意，那么音頻的無限循環(huán)一定會使情況變得更糟。

而一種名為loop的布爾屬性正好迎合了這種情況：

<audiosrc="witchitalineman.mp3nautoplayloop>

</audio>

以這樣的方式將loop屬性與autoplay屬性結(jié)合使用會令情況變得十分糟糕。

3.2.1control屬性

除了惡意用途，audio元素同樣也有積極的用途。給予用戶對音頻文件的回放控制權(quán)

是一個(gè)明智的做法，通過使用布爾屬性control,該操作很容易實(shí)現(xiàn)：

<audiosrc="witchitalineman.mp3,'controls></audio>

control屬性的存在促使瀏覽器為播放音頻、暫停音頻以及調(diào)節(jié)音量提供本地控制，

如圖3.5所示。

圖3.5使用control來顯示音頻的播放、暫停和音量控制。

如果開發(fā)人員不喜歡瀏覽器的本地控制，則可以創(chuàng)建自己的控制。通過使用

JavaScript可以與AudioAPI進(jìn)行交互，這使得開發(fā)人員可以訪問play和pause等類函數(shù)

和volume等屬性。下面顯示了一個(gè)粗略的示例，該示例使用了button元素以及令人討厭

的內(nèi)聯(lián)事件處理器(見圖3.6)：

<audioid="player"src="witchitaIineman.mp3H>

</audio>

<div>

<button?

onclick=,,document.getElementById('player').play()">?

Play

</button>

<button?

onclick=ndocument.getElementById('player').pause()">?

Pause

</button>

<button?

onclick="document.getElementById('player').volume?

+=0.1">

VolumeUp

</button>

<button?

onclick="document.getElementByld('player').volume?

-=0.1">

VolumeDown

</button>

</div>

Pause'iUpiVolumeDown:

圖3.6button元素生成的控件。

3.2.2緩沖

在一段時(shí)期內(nèi)，HTML5規(guī)范曾包含audio元素的另一個(gè)布爾屬性。autobuffer屬性

比autoplay屬性要好用一些。該屬性為程序員提供了一種通知瀏覽器的方法：雖然音頻

文件不會自動播放，但它可能會在某些時(shí)刻播放，所以瀏覽器需要在后臺預(yù)先加載文件。

這本可以成為一個(gè)非常有用的屬性，但遺憾的是，Safari的發(fā)展更進(jìn)了一步。無論

autobuffer屬性是否存在，它都會預(yù)加載音頻文件。需要注意的是，因?yàn)閍utobuffer是一

個(gè)布爾屬性，所有無法阻止Safari瀏覽器對音頻的預(yù)加載，即autobuffer="false”與

autobuffer="true”的效果是一樣的。而且，為該屬性賦予其他的值也不會有任何區(qū)別。㈤

現(xiàn)在，autobuffer屬性已經(jīng)被preload屬性取代。preload不是一個(gè)布爾屬性，該屬

性可以接受的值有三種：none、auto和metadata。如果使用preload="none",就可以

明確地告知瀏覽器無需預(yù)先加載音頻：

<audiosrc="witchitalineman.mp3"controlspreload="none">

</audio>

如果頁面中只有一個(gè)音頻元素，則可以使用preload="auto"。但使用的audio元素?cái)?shù)

量越多，受到過度預(yù)加載打擊的訪問者帶寬就越大。

3.2.3播放格式的不同

audio元素似乎很完美，但它仍在某些方面存在問題。

audio元素的問題并不在于規(guī)范，而在于音頻格式。

雖然MP3格式已經(jīng)十分普遍，但它并不是開放的格式。因?yàn)樵摳袷绞鞘艿綄＠Ｗo(hù)

的，所以，如果不付費(fèi)，就無法對MP3文件進(jìn)行解碼。對于蘋果或Adobe一類的大公司,

這是可以接受的；但對于規(guī)模較小的公司或開放源碼的團(tuán)體就不那么容易了。因此，

Safari很樂意采用MP3文件,而Firefox卻并非如此。

還有一些其他的音頻格式。Vorbis格式的編解碼器一通常交付為.ogg文件一不受任

何專利的約束。Firefox支持OggVorbis,而Safari瀏覽器對此卻不支持。

幸運(yùn)的是，有一種方法可以在使用audio元素時(shí)不必在文件格式之間進(jìn)行艱難的抉擇。

該方法不是在<audio>標(biāo)簽中使用src屬性，而是通過使用source元素來指定多種文件格

式：

<audiocontr