在這篇文章中，我將給大家分享html5構建頁面的小錯誤和不好的實踐方法，讓我們在以后的工作中避免這些錯誤。不要把 Section 當成容器來定義樣式我們經常看到的一個錯誤，就是武斷的將 div 標簽用 section 標簽來替代，特別是將作為包圍容器的 div 用 section 來替換。在XHTML或者HTML4中，我們將會看到類似下面的代碼： 直觀的看，上面的例子是錯誤的： section 并不是一個容器. section 元素是有語意的區段，幫助構建文檔大綱。它應該包含標題。如果你要尋找一個可以包含頁面的元素（不論是 HTML 或者 XHTML ），通常的做法是直接對 body 標簽定義樣式就像Kroc Camen描述的那樣子，如果你還需要額外的元素來定義樣式，使用 div ,就像Dr Mike 闡述的那樣, div并沒有滅亡，如果這里沒有其它更合適的，div可能是你最合適的選擇。記住這點，這里我們重新修正了上面的例子，通過使用兩個新角色。（你是否需要額外的 div 取決于你的設計。） 如果你還是無法確定哪一個元素更適合使用，我建議你去查看HTML5 sectioning content element flowchart來讓你繼續前行。只在需要的時候使用 hgroup 和 header 標簽使用標記的時候寫入了一些并不需要的現象這是不合理的。不幸的是，經常發現大家在并不需要的地方使用 header 和 hgroup 標簽。你可以跟進我們關于 header 和 hgroup 的最新進展，下面是我的簡單歸納： header 元素通常是通常作為一組解釋或者導航輔助工具,通常包含section的標題. hgroup 元素會將當有副標題/子標題,各類標識文字時,對 h1 到 h6 標題進行群組,將其作為section的標題.過度使用的 header 你肯定知道,在一個文檔中,可以使用多次 header 標簽,下面就是一種很受大家歡迎的模式: 如果你的 header 標簽只包含一個標題元素時,就不要使用 header 標簽了. article 標簽肯定會讓你的標題在文檔大綱中顯現出來,而且因為 header 并不包含多重內容(就像定義中描述的那樣子),我們為何要增加而外的代碼呢?應該像下面這樣簡單才可以: hgroup 不合理使用在標題的這個主題上,經常看到使用 hgroup 的錯誤案例.在下面這種情況下你不能將 header 標簽和 hgroup 標簽一起使用: 這里只有一個標題, 或者 hgroup 本身就夠了(比如:不需要 hgroup )第一種情形看上去是下面的樣子: 當 header 標簽的子元素只有 hgroup 的時候,為什么我們還需要一個額外的 header ?如果沒有額外的元素放到 header 中(比如 hgroup 的兄弟元素),我們直接將 header 元素去掉就好. 不要將所有的鏈接列表都放到 nav 標簽在HTML5新增的30個元素中(在我們寫這篇文章的時候),我們在構建更具語義/結構化的標簽的時候,我們的選擇變得太豐富.也就是說我們對現在給我們提供的這些超級有語義的標簽,我們可能會濫用. nav 就是一個很悲劇的例子.在規范中的描述是這樣的:The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.Note: Not all groups of links on a page need to be in a nav element the element is primarily intended for sections that consist of major navigation blocks. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases; while a nav element can be used in such cases, it is usually unnecessary. WHATWG HTML spec這里面的關鍵詞是 重要 導航.我們可能會對 重要 有不同的定義,但是我的理解是: 主要導航 網站搜索 二級導航(這個能是有爭議的) 頁面內鏈接(比如一篇很長的文章)雖然并沒有對錯之分,但根據我的理解和一個民意投票讓我覺得在下面這些情形下,我不會使用 nav 標簽: 社交類的鏈接（雖然有些社交類的鏈接也是主要的鏈接，比如關于我About me和品味Flavours ） 博客文章的標簽 博客文章的分類列表 第三級導航如果你不能確定是否使用 nav ，那就先對你問一下下面的幾個問題： 者是否是一個主要鏈接？ ，你可以根據下面的幾個因素來回答你剛才的問題： 如果用 section 和標題標簽能夠解決你的問題，那就不要去使用 nav Hixie on IRC 你是不是為了增加可訪問性而增加的一個快捷跳轉鏈接呢？如果上面的回答都是 不 ，那可能就不適合使用 nav . figure 元素的錯誤 figure 和經常與它合伙作案的 figcaption ，是很難掌握的標簽，下面是經常看到的一些小錯誤。并不是所有的圖片都是figure（注：比較難理解阿，image=圖片，figure=圖形）之前，我曾經說過不要寫那些不需要的標簽。這個錯誤也是相同的。我經常看到一個網站上的每張圖片都有 figure 標簽。這些額外增加的標簽并不會給你帶來任何的益處，并且還增加了你自己的工作強度和讓自己的內容變得更難理解。在規范中關于 figure 的解釋如下： 某些流內容，可以有標題，自我包含并且通常作為一個單元獨立于內文檔流之外。 在那里有完美的表述，就是它可以被從主內容中移除 比如放到邊攔，而對文檔流沒有影響。 如果僅僅是一張表現類的圖片而且和文檔中其他的內容沒有關系的話，那就不需要使用 figure . 這張圖片需要對上下文的內容作出解釋嗎？ ，如果答案是 否 ，那就可能不是 figure (可能是 aside ), 我能把它移到附錄里面嗎？ ，如果這兩個問題的答案都是 是 ，那就可能是 figure .你的標志不是一個 figure 將上面的延伸開來，對你的logo也是這樣。下面是兩組我找到的有規律的代碼片斷： figure img src= /img/mylogo.png alt= My company >這里就不需要說啥了，這是很明顯的錯誤，可能你認為我們說的是不是將logo放在H1標簽里面，但是我們在這里并不討論這個問題。讓我們迷惑的是 figure 元素。 figure 標簽只用在當有上下文需要說明或者被 section 包圍的時候。我這里要說的是你的logo可能很少會被這種情況下使用。很簡單，那就不要去這樣做，你需要的僅僅是下面的樣子。 figure只能用在標簽上的誤解另一個對 figure 的誤解就是我們通常認為它只能用在圖片上面。事實上并不是這樣子的，它可以被用在 video audio , 一個圖標 (比如 SVG , ), 一個引用, 一個表格, 一段代碼, 一段散文, 或者任何和這些相關的組合. 不要把你的 figure 標簽僅僅局限在圖片上。我們網頁制作師的任務就是用標簽更準確的描述內容。 這里有一篇更深入講解 figure 的文章I wrote about figure ，很值得閱讀的。不要去使用那些不必要的type屬性這可能是我們最常見的一些問題，它們并不是真正的錯誤，但我覺得我們的最好實踐還是盡量避免這種模式。 在HTML5中，我們并不需要給 script 和 script 增加 type 屬性，如果這些從CMS默認添加的內容中移出是很痛苦的事情，那當你手工編碼的時候還寫入它們或者你能完全的控制你的模板時候你完全可以刪掉它們。因為所有的瀏覽器都會將 script 解析成Javascript和 script 標簽是CSS，你不再需要那個type屬性了： !-- Don t copy this code! It s attribute overload! -- link type= text/css rel= stylesheet href= css/styles.css / script type= text/javascript src= js/scripts.js /script 你也能夠對編碼的設置作出省略。Mark Pilgrim在Dive into HTML5的語義化一章中作出了解釋。不要包含錯誤的標單屬性你可能發現 html5 引入了很多新的表單屬性。現在我就給大家講講一些不合適的使用。布爾值屬性新引入的標簽屬性有幾個是布爾類型的，它們的標簽行為基本接近。這些屬性包括： autofocus autocomplete required坦白的說，下面的這種情況對我來說并不常見，但我們從 required 作為例子，如下： !-- Don t copy this code! It s wrong! -- input type= email name= email required= true / !-- Another bad example -- input type= email name= email required= 1 / 基本上看，這段代碼并不會帶來危害。客戶端對 HTML的解析遇到 required 標簽屬性時，他的功能就會生效。但是當我們將代碼修改，錄入 required= false 的情況呢？ !-- Don t copy this code! It s wrong! -- input type= email name= email required= false / 解析的時候依然會遇到 required 屬性，雖然你希望加入的行為是 假，它依然會被解析成 真。 這里有三種合理的方法讓布爾值生效。（第二種和第三種方案只有你在寫 XHTML 解析的時候需要）我們上面的例子可以寫成下面的樣子： 總結 對我來說，我無法將所以得蹩腳的代碼模式都展示在這里，但是上面說的這些都是我們經常遇到的。中文原文：如何避免 HTML5 的常見誤區英文原文：Avoiding common HTML5 mistakeshtml教程
