��ֿڹ��,��H��ǿJ�ֱ��

HTML5網站設計

分類：瀏覽次數：32064 2018-11-26 00:00:00

滿意回答

2018-11-26 00:00:00

法國大革命是極端的政治和社會變革時期。這種革命熱情也被傾注于對計時系統的改革中。在一段時期內，法蘭西共和國引入了十進制計時制，即1天分為10小時，且1小時分為100分鐘。該計時制的邏輯性和清晰性明顯優于六十進制的計時制。

但十進制的計時制失敗了。沒有人使用這種計時制度。而XHT ?ML 2的命運與之相似。W3C再次證明了法國大革命的教訓：改變現有的行為習慣是非常非常困難的。

QQ截圖20180905123710

2.1 設計原則?

為了避免過去所犯的錯誤，WHATWG起草了一系列設計原則以指導HTML5的開發。其中一項主要原則是“支持已有內容”。這意味著對于HTML5來說，并不存在創立的起始時間。

XHTML 2試圖廢棄之前的一切。而與之不同的是，HTML5建立在現有規范和實現的基礎之上。HTML 4.01的大部分內容在HTML5中都得到了保留。

一些其他的設計原則，例如“不要做重復的工作”和“沿著足跡鋪路”的意思是，對于網頁設計師來說，如果存在一種普遍的方法來完成某項任務，那么即使它不是最好的方法，也應該被編入HTML5中，也就是說“別去修理沒壞的東西”。

涉足過微格式（//microformats.org）的網頁設計師應該十分熟悉這些

設計原則。HTML5社區具有同樣的務實方針以實現標準格式的統一，所以無需擔心理論問題。

這種態度體現在“最終用戶優先”的設計原則中，該原則規定：在發生沖突時，最終用戶優先，其次是作者、實現者、標準制定者，最后才是理論上的完滿。

伊恩·希克森已經多次表示，瀏覽器廠商才是HTML5真正的仲裁者。如果瀏覽器供應商拒絕支持某項協議，那么在規范中添加該協議就變得沒有任何意義，因為這會使規范不夠切合實際。根據最終用戶優先的原則，網頁設計師的意見更具有意義。如果網頁設計師拒絕使用規范的某些內容，那么規范同樣不夠切合實際。

2.2 切合現實

持續的內部張力推動了HTML5的創立。一方面，規范需要足夠強大，從而有能力支持創建網頁應用程序，另一方面，雖然大多數現有內容都處于完全混亂的狀態，但是HTML5仍需要支持已有的內容。如果 HTML5的規范在某一個方向上偏離得太遠，那么它將重蹈XHTML 2的覆轍。但是，如果它在另一個相反的方向上偏離得太遠，那么它就會認為<font>標簽和表單是萬能的，因為這兩者是大量網頁建立的基礎。

這是一種微妙的平衡，保持這種平衡需要務實且冷靜的方法。

2.3 錯誤處理?

HTML5不僅聲明了瀏覽器應該如何處理規范格式的標記，還首次規范了瀏覽器該如何處理格式不規范的文件。

瀏覽器廠商曾不得不獨自研究如何處理錯誤。無論最流行的瀏覽器做出怎樣的嘗試，該過程通常都會涉及逆向工程，這會耗費瀏覽器廠商的時間。與其浪費時間模仿競爭對手處理有缺陷的標記，倒不如嘗試實現新功能。

在HTML5中定義錯誤處理恐怕難以實現。雖然HTML5具有與HTML 4.01完全相同的元素和屬性，并且完全沒有添加新特性，但在2012年年底之前完成錯誤處理的定義仍然是徒勞的。

網頁設計人員可能對錯誤處理不大感興趣，特別是在他們一開始就會編寫有效并且格式規范的文件的情況下，但錯誤處理對于瀏覽器廠商來說卻非常重要。以往的標記規范都是為創作者編寫的，而HTML5卻是為創作者和實施者編寫的。網頁設計人員在細讀規范時應牢記這一點。這就解釋了為什么HTML5規范的內容如此之多，同時也解釋了為什么該規范含有一些通常為專家所保留的細節。

2.4 DOCTYPE：形式更簡潔

文檔類型聲明（Document Type Declaration）簡稱為doctype，一直用于指定文檔所編寫的標記類型。

這些doctype看起來并不易讀，但它們以其獨特的方式簡單地說明了：“該文檔用HTML 4.01編寫”或“該文檔用XHTML 1.0編寫”。

如果doctype聲稱“該文檔用HTML5編寫”，那么按道理其中應該會出現數字5。但事實并非如此。HTML5的doctype如下所示：

<!DOCTYPE html>

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

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

第一次看到HTML5的doctype的時候，我認為這是高度傲慢的結果。心想：“難道他們真相信這就是標記規范的最終版了嗎？”

然而事實上，HTML5的doctype是非常務實的。由于HTML5需要支持現有內容，所以其doctype可以應用于現有的HTML 4.01文檔和XHTML 1.0文檔。任何未來版本的HTML也需要支持HTML5中的現有內容，因此應用版本號來標記文檔的觀念是有缺陷的。

事實上，doctype并不那么重要。假設需要為一個文檔提供HTML 4.01的doctype。如果該文檔中包含來自另一個規范的元素，如HTML 3.2或HTML5，那么瀏覽器將仍然呈現該文檔的這一部分。這是因為瀏覽器支持的是特性，而非doctype。

起初，文檔類型聲明（Document Type Declaration）是為驗證器而非為瀏覽器而設計的。瀏覽器僅在“doctype轉換”的情況下才會關注doctype—“doctype轉換”（doctypy switching）是一個聰明的小黑客，它根據是否存在合適的doctype來轉換顯示模式，即怪異模式（quirks mode）或標準模式（standard mode）。

為了確保瀏覽器以標準模式顯示，至少需要HTML5的doctype。事實上，這是包含doctype的唯一原因。不用HTML5的doctype編寫的HTML文檔仍然是有效的HTML5。

2.5 保持簡潔?

HTML5中簡化的不僅僅是doctype。

如果想要指定一個標記文檔的字符編碼，那么最好的方法就是確保服務器發送了正確的Content-Type文件頭（header）。如果想要雙倍保險，那么也可以使用<meta>標簽來指定字符集。<meta>是一個用 HTML 4.01 編寫的文件聲明：下面的示例實現了與前一示例在HTML5中所實現的相同功能，但其實現方式更加令人印象深刻：

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

另一處可以縮減字符數量的地方是<script>標簽。常見的做法是為script元素添加type屬性，屬性值為“text / javascript”：

瀏覽器并不需要該屬性。它們假定該腳本已用JavaScript編寫。JavaScript是最流行的網頁腳本語言（實際上，JavaScript也是唯一的一種網絡腳本語言）：

下面的示例實現了與前一示例在HTML5中所實現的相同功能，但其實現方式更加令人印象深刻：

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

另一處可以縮減字符數量的地方是<script>標簽。常見的做法是為script元素添加type屬性，屬性值為“text / javascript”：

瀏覽器并不需要該屬性。它們假定該腳本已用JavaScript編寫。JavaScript是最流行的網頁腳本語言（實際上，JavaScript也是唯一的一種網絡腳本語言）：

2.6 語法：以自己的方式進行標記

一些編程語言，如Python，以其特殊的方式編寫說明。使用空格來縮進代碼是強制性的，空格很重要。而其他編程語言，如JavaScript，卻不在格式方面作任何要求，每一行開頭是否空格并不那么重要。

如果與一些程序員同處一室并說出“重要的空格”之類的話，那么就會導致一整晚不斷升溫的激烈辯論。

關于空格重要性的辯論核心存在一個基本的哲學問題：匯編語言應該保持特定的匯編風格，還是編寫者可以按自己喜歡的風格編寫？

標記并不需要空格。如果想要在每次嵌套元素時都添加新的一行和縮進，則需

要添加空格，但瀏覽器和校驗器并不需要空格。這并不意味著標記對所有情況都適用。有些種類的標記遵循更為嚴格的編寫風格。

在XHTML 1.0之前，使用大寫還是小寫來編寫標簽并不重要。是否引用屬性也同樣不那么重要。甚至對于某些元素來說，是否包含結束標記都不會造成任何影響。

XHTML 1.0強制執行XML的語法：所有標簽都必須為小寫，所有屬性都必須加引號，所有元素都必須包含有結束標記。對于獨立元素的特殊情況，例如br，以標記結束替換為以斜線<br />結束。

如果使用HTML5，那么任何格式的命令都可以，無論是大寫、小寫、帶引號的、不帶引號的、帶有結束符號的和不帶有結束符號的，使用哪種格式完全取決于程序員。

多年來，我一直在使用XHTML 1.0的doctype。這是因為我喜歡按照一種特定的樣式編寫程序，從而也比較喜歡W3C驗證對固定樣式的強制要求。現在，我正在使用的是HTML5，所以執行哪種編寫樣式可以由自己決定。

我可以理解為什么有些人不喜歡HTML5語法的隨意性，因為這似乎是從最佳范例向后的退步。有些人甚至會說，HTML5對語法的寬松限制會導致不良標記。雖然我并不這樣認為，但可以理解為什么這會成為一個備受關注的問題。因為這就好像是一種強制使用空格的匯編語言突然在編程原則上變得寬容起來。

就個人而言，我可以接受HTML5語法的隨意性。但與此同時，我也強迫自己使用個人青睞的編寫風格。不過，我更希望見到更多的、可以以一種特定風格測試標記的工具。在編程界，這些工具被稱為lint工具，即標記可疑編碼范例的程序。驗證器檢查的是doctype，而用于標記的lint工具卻與之不同；這兩者若可以結合為一種精益且介于兩者之間的lint驗證設備，那將會更好。

完成這樣設備的網頁設計師將會獲得來自世界各地的人們永久的尊重和敬佩。

2.7 我們不使用這種語言?

對于舊版本的HTML，從規范中移除先前存在的元素或屬性的過程被稱為廢棄。網頁設計師不應該使用、回顧甚至提及已廢棄的元素。

HTML5中不含有被廢棄的元素或屬性，但卻有大量過時的元素和屬性。

“過時”與“廢棄”在含義上有著微妙的區別。

由于HTML5的目的是向后兼容已有內容，因此其規范必須承認先前存在的元素，即使這些元素已不包含在HTML5中。這將使情況變得略顯混亂，因為其規范還聲稱“編寫人員請不要使用該元素”以及“瀏覽器應該以此方式呈現該元素”。如果一個元素被廢棄，那么它不應在規范中被提到；但是由于該元素是過時的，為了照顧瀏覽器，它也被包含進來了。

除非正在開發一款瀏覽器，否則可以用對待廢棄元素和屬性的方式來對待過時的元素和屬性，即不要在網頁中使用它們。

如果堅持使用過時的元素或屬性，那么文件將變得“不符合要求”。瀏覽器將執行一切行得通的程序，但其他網站可能會對此表示不滿。

過時的元素

frame、frameset和noframes元素都已經過時了。沒有人會懷念它們。acronym元素也已經過時了，因此導致了多年的討論，這些時間本可以被用在更有意義的事情上。不要為acronym元素感到惋惜，使用abbr元素來代替它就可以了。首字母縮寫（acronym）和縮寫（abbreviation）的確有所不同—首字母縮寫作為一個詞發音，例如NATO和SCUBA，但請記住，所有的首字母縮寫都屬于縮寫，但并不是所有的縮寫都是首字母縮寫。

HTML5中的顯示元素，如font、big、center和strike都已經過時了。實際上，它們在多年前就已經過時了。而使用CSS屬性，如font-size和text-align，則更容易獲得相同的顯示效果。同樣，顯示元素的屬性，如bgcolor、cellspacing、cellpadding和valign也都已經過時了,使用CSS來代替這些屬性就可以了。

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

2.8 轉變（CH-CH變化）

元素big已經過時了，但元素small卻還沒有。通過重新定義small的含義，這種顯著的矛盾已經得到解決。small的含義不再是其字面意義，即“在小號字體下進行顯示”。相反，其語義值變為法律術語、條款或附屬細則以小號字體顯示。

當然，十有八九，開發人員會以小號字體顯示附屬細則，但重點是該元素的字面意義已被取代。

元素b曾表示“用粗體顯示”。現在，它被用來將一些文本“偏離正常的樣式而不具有任何額外的重要性”。如果文本具有額外的重要性，那么使用該元素則更為合適。

元素i也不再意味著“傾斜”。它表示文本中“另一種的語氣或情緒”。同樣，該元素也不表達任何重要性或重點。如果需要強調，則要使用em元素。

這些變化聽起來可能像是文字游戲。它們的確是文字游戲，但它們也有利于增強HTML5的設備獨立性。如果仔細考慮“加粗”和“傾斜”，那么它們僅在視覺媒介（如屏幕或頁面）中才能解釋得通。通過消除這些元素定義中的視覺偏差，HTML5的規范可與非可視化用戶代理（如屏幕閱讀器）保持相關。這樣做可以避免設計師的思維被禁錮在視覺顯示環境之內。

2.8.1 cite元素

HTML5對cite元素進行了重新定義。cite元素原來表示的是“對其他參考資料的引用”，但它現在的意思是“一部作品的標題”。通常，被引用的參考為作品的標題，例如一本書或一部電影，但其根源很可能是一個人。在HTML5之前，可以使用cite來標記這個人的名字。但現在，這種做法被明令禁止—關于向后兼容性僅僅討論這么多。

對于這種修正的理由是：瀏覽器將<cite>標簽之間的文本格式更改為斜體；作品的標題通常是斜體的；人名通常不是斜體。因此，cite元素不應該被用于標記人名。

但這是完全錯誤的。我贊成HTML5向瀏覽器學習，但這種情況屬于主次顛倒。

幸運的是，驗證器無法分辨起始<cite>標簽和結束</cite>標簽之間的文本是否是指向人的，所以沒有什么能阻止網頁設計師用一種合理的、向下兼容的方式來使用cite元素。

2.8.2 增強型a元素

先前已有元素的變化僅僅是創造性的文字游戲，但HTML5對一個元素進行了更為有效的改造。

毫無疑問，a元素是HTML中最重要的元素。該元素將文本轉換成超文本，相

當于萬維網的結締組織。

a元素是一個內嵌元素。如果想要將一個標題或一個段落轉化為超鏈接，則需使用多個a元素：

[代碼]

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

[代碼]

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

將多個元素包裝在一個元素中，這看起來似乎是一個巨大的變化。而且，要想支持這種新的鏈接模式，大多數瀏覽器并不需要做很多工作。雖然這種標記直到現在才成為合法的，但大多數瀏覽器已經支持了這種新的模式。

這似乎有些違背常理：瀏覽器應該理所當然地執行已有的規范嗎？事實上正相反，是最新的規范正在記錄瀏覽器所執行的操作。

2.9 閃亮的新工具：JavaScript API

如果想要獲取關于CSS的文檔，需要查閱CSS規范。如果尋找的是有關標記的文檔，需要查閱HTML規范。但是，哪里可以查閱JavaScript API的文檔，例如document.write、innerHTML和window.hitory？JavaScript規范所涉及的全部是編程語言，因此無法獲得任何與瀏覽器API有關的內容。

到現在為止，瀏覽器一直獨立創建和執行JavaScript API并相互借鑒。HTML5對這些API的記錄是一勞永逸的，因為這可以確保較好的兼容性。

在標記規范中包含JavaScript規范聽起來可能有些奇怪，但要記住，HTML5是由Web Apps 1.0發展而來的。JavaScript是制作Web應用過程中不可缺少的一部分。

HTML5規范中的所有章節都致力于創建Web應用的新API，其中包含一個Undo-Manager——它使得瀏覽器能夠跟蹤文檔變更。該規范中有一節介紹了如何使用緩存清單來創建離線Web應用。另外，該規范對拖放功能也進行了詳細描述。

與往常一樣，如果存在已有的實現，那么規范將在其基礎上建立，而非將一切推倒重來。微軟的IE瀏覽器在很多年前就已經包含了拖放API，這也是HTML5拖放

的基礎。遺憾的是，微軟的API是有問題的。如果以前的基礎并不適用，那么重新開始也不見得是壞主意。

HTML5中的API十分強大。它們完全超出了我的能力范疇，所以我將這些內容留給更優秀的開發人員來編寫。這些API值得用一本單獨的書來介紹。

與此同時，對于網頁設計師來說，HTML5中仍存在許多新鮮事物。這些內容將在下一章進行說明。

標簽：