一、不要使用section作為div的替代品
人們在標籤使用中最常見到的錯誤之一就是隨意將 HTML5 的 <section>等價於 <div>——具體地說，就是直接用作替代品(用於樣式)。在 XHTML 或者 HTML4 中，我們常看到這樣的代碼：
<!-- HTML 4-style code -->
<div id="wrapper">
<div id="header">
<h1>My super duper page</h1>
<!-- Header content -->
</div>
<div id="main">
<!-- Page content -->
</div>
<div id="secondary">
<!-- Secondary content -->
</div>
<div id="footer">
<!-- Footer content -->
</div>
</div>而現在在 HTML5 中，會是這樣：
<!-- 請不要複製這些代碼！這是錯誤的！ -->
<section id="wrapper">
<header>
<h1>My super duper page</h1>
<!-- Header content -->
</header>
<section id="main">
<!-- Page content -->
</section>
<section id="secondary">
<!-- Secondary content -->
</section>
<footer>
<!-- Footer content -->
</footer>
</section>這樣使用並不正確：<section> 並不是樣式容器。section 元素表示的是內容中用來幫助構建文檔概要的語義部分。它應該包含一個頭部。如果你想找一個用作頁面容器的元素(就像 HTML 或者 XHTML 的風格)，那麼考慮如 Kroc Camen 所說，直接把樣式寫到 body 元素上吧。如果你仍然需要額外的樣式容器，還是繼續使用 div 吧。
基於上述思想，下面才是正確的使用 HTML5 和一些 ARIA roles 特性的例子（注意，根據你自己的設計，你也可能需要加入 div）
<body>
<header>
<h1>My super duper page</h1>
<!-- Header content -->
</header>
<div role="main">
<!-- Page content -->
</div>
<aside role="complementary">
<!-- Secondary content -->
</aside>
<footer>
<!-- Footer content -->
</footer>
</body>如果你還是無法確定使用哪種元素，那麼我建議你參考 HTML5 sectioning content element flowchart。
二、只在需要的時候使用header和hgroup
寫不需要寫的標籤當然是毫無意義的。不幸的是，我經常看到 header 和 hgroup 被無意義的濫用。你可以閱讀一下關於 header 和 hgroup 元素的兩篇文章做一個詳細的了解，其中內容我簡單總結如下：
‧header 元素表示的是一組介紹性或者導航性質的輔助文字，經常用作 section 的頭部。
‧當頭部有多層結構時，比如有子頭部，副標題，各種標識文字等，使用 hgroup 將 h1-h6 元素組合起來作為 section 的頭部。
header的濫用
由於 header 可以在一個文檔中使用多次，可能使得這樣代碼風格受到歡迎：
<!-- 請不要複製這段代碼！此處並不需要 header -->
<article>
<header>
<h1>My best blog post</h1>
</header>
<!-- Article content -->
</article>如果你的 header 元素只包含一個頭部元素，那麼丟棄 header 元素吧。既然 article 元素已經保證了頭部會出現在文檔概要中，而 header 又不能包含多個元素（如上文所定義的），那麼為什麼要寫多餘的代碼。簡單點寫成這樣就行了：
<article> <h1>My best blog post</h1> <!-- Article content --> </article>
<hgroup> 的錯誤使用
在 headers 這個主題上，我也經常看到 hgroup 的錯誤使用。有時候不應該同時使用 hgroup 和 header:
‧如果只有一個子頭部
‧如果 hgroup 自己就能工作的很好...這不廢話麼
第一個問題一般是這樣的：
<!-- 請不要複製這段代碼!此處不需要 hgroup -->
<header>
<hgroup>
<h1>My best blog post</h1>
</hgroup>
<p>by Rich Clark</p>
</header>此例中，直接拿掉 hgroup，讓 heading 裸奔吧。
<header> <h1>My best blog post</h1> <p>by Rich Clark</p> </header>
第二個問題是另一個不必要的例子：
<!-- 請不要複製這段代碼!此處不需要 header -->
<header>
<hgroup>
<h1>My company</h1>
<h2>Established 1893</h2>
</hgroup>
</header>如果 header 唯一的子元素是 hgroup，那還要 header 幹神馬[蓮按：神馬是大陸流行網絡用語，是“什麼”的意思]？如果 header 中沒有其他的元素（比如多個 hgroup），還是直接拿掉 header 吧。
<hgroup> <h1>My company</h1> <h2>Established 1893</h2> </hgroup>
關於 <hgroup> 更多的例子和解釋，請參閱相關文章
三、不要把所有列表式的鏈接放在 nav 裏
隨著 HTML5 引入了 30 個新元素（截止到原文發布時），我們在構造語義化和結構化的標籤時的選擇也變得有些不慎重。也就是說，我們不應該濫用超語義化的元素。不幸的是，nav 就是這樣一個被濫用的例子。nav 元素的規範描述如下：
nav 元素表示頁面中鏈接到其他頁面或者本頁面其他部分的區塊；包含導航連接的區塊。
注意：不是所有頁面上的鏈接都需要放在 nav 元素中——這個元素本意是用作主要的導航區塊。舉個具體的例子，在 footer 中經常會有衆多的鏈接，比如服務條款，主頁，版權聲明頁等等。footer 元素自身已經足以應付這些情況，雖然 nav 元素也可以用在這裏，但通常我們認為是不必要的。
WHATWG HTML spec
關鍵的詞語是“主要的”導航。當然我們可以互相噴上一整天什麼叫做“主要的”。而我個人是這樣定義的：
‧主要的導航
‧站內搜索
‧二級導航（略有爭議）
‧頁面內導航（比如很長的文章）
既然並沒有絕對的對錯，所以根據一個非正式投票以及我自己的解釋，以下的情況，不管你放不放，我反正不放在 <nav> 中：
‧分頁控制
‧社交鏈接（雖然有些社交鏈接也是主要導航，比如“關於”“收藏”）
‧博客文章的標籤
‧博客文章的分類
‧三級導航
‧過長的 footer
如果你不確定是否要將一系列的鏈接放在 nav 中，問你自己：“它是主要的導航嗎？”為了幫助你回答這個問題，考慮以下首要原則：
‧如果使用 section 和 hx 也同樣合適，那麼不要用 nav — Hixie on IRC
‧為了方便訪問，你會在某個“快捷跳轉”中給這個 nav 標籤加一個鏈接嗎？
如果這些問題的答案是“不”，那就跟 <nav> 鞠個躬，然後獨自離開吧。
四、figure 元素的常見錯誤
figure 以及 figcaption 的正確使用，確實是難以駕馭。讓我們來看看一些常見的錯誤。
不是所有的圖片都是figure
上文中，我曾告訴各位不要寫不必要的代碼。這個錯誤也是同樣的道理。我看到很多網站把所有的圖片都寫作 figure。看在圖片的份上請不要給它加額外的標籤了。你只是讓你自己蛋疼[蓮按：蛋疼亦是大陸流行網絡用語，意思是吃飽了撐做無聊的事]，而並不能使你的頁面內容更清晰。
規範中將 figure 描述為“一些流動的內容，有時候會有包含於自身的標題說明。一般在文檔流中會作為獨立的單元引用。”這正是 figure 的美妙之處——它可以從主內容頁移動到 sidebar 中，而不影響文檔流。
這些問題也包含在之前提到的 HTML5 element flowchart 中。
如果純粹只是為了呈現的圖，也不在文檔其他地方引用，那就絕對不是 <figure> 。其他視情況而定，但一開始可以問自己：“這個圖片是否必須和上下文有關？”如果不是，那可能也不是 <figure>（也許是個<aside>）。繼續：“我可以把它移動到附錄中嗎？”如果兩個問題都符合，則它可能是 <figure>。
Logo並不是figure
進一步的說，logo也不適用於 figure。下面是我常見的一些代碼片段：
<!-- 請不要複製這段代碼!這是錯的 -->
<header>
<h1>
<figure>
<img src="/img/mylogo.png" alt="My company" class="hide" />
</figure>
My company name
</h1>
</header>
<!-- 請不要複製這段代碼!這也是錯的 -->
<header>
<figure>
<img src="/img/mylogo.png" alt="My company" />
</figure>
</header>沒什麼好說的了。這就是很普通的錯誤。我們可以為 logo 是否應該是 H1 標籤而互相噴到牛都放完回家了，但這裏不是我們討論的焦點。真正的問題在於 figure 元素的濫用。figure 只應該被引用在文檔中，或者被 section 元素圍繞。我想你的 logo 並不太可能以這樣的方式引用吧。很簡單，請勿使用 figure。你只需要這樣做:
<header> <h1>My company name</h1> <!-- More stuff in here --> </header>
Figure 也不僅僅只是圖片
另一個常見的關於 figure 的誤解是它只被圖片使用。figure 可以是視頻，音頻，圖表，一段引用文字，表格，一段代碼，一段散文，以及任何它們或者其他的組合。不要把 figure 局限於圖片。web 標準的職責是精確的用標籤描述內容。
五、不要使用不必要的type屬性
這是個常見的問題，但並不是一個錯誤，我認為我們應該通過最佳實踐來避免這種風格。
在 HTML5中，script 和 style 元素不再需要 type 屬性。然而這些很可能會被你的 CMS 自動加上，所以要移除也不是那麼的輕鬆。但如果你是手工編碼或者你完全可以控制你的模板的話，那真的沒有什麼理由再去包含 type 屬性。所有的瀏覽器都認為腳本是 javascript 而樣式是 css 樣式，你沒必要再多此一舉了。
<!-- 請不要複製這段代碼!它太沉餘了! --> <link type="text/css" rel="stylesheet" href="css/styles.css" /> <script type="text/javascript" src="js/scripts" /></script>
其實只需要這樣寫：
<link rel="stylesheet" href="css/styles.css" /> <script src="js/scripts" /></script>
甚至指定字符集的代碼都可以省略掉。Mark Pilgrim 在 Dive into HTML5 的語義化一章中作出了解釋。
六、form屬性的錯誤使用
HTML5 引入了一些 form 的新屬性，以下是一些使用上的注意事項：
布爾屬性
一些多媒體元素和其他元素也具有布爾屬性。這裏所說的規則也同樣適用。
有一些新的 form 屬性是布爾型的，意味著它們只要出現在標籤中，就保證了相應的行為已經設置。這些屬性包括：
‧autofocus
‧autocomplete
‧required
坦白的說，我很少看到這樣的。以 required 為例，常見的是下面這種：
<!-- 請不要複製這段代碼! 這是錯的! --> <input type="email" name="email" required="true" /> <!-- 另一個錯誤的例子 --> <input type="email" name="email" required="1" />
嚴格來說，這並沒有大礙。瀏覽器的 HTML 解析器只要看到 required 屬性出現在標籤中，那麼它的功能就會被應用。但是如果你反過來寫 equired=”false”呢？
<!-- 請不要複製這段代碼! 這是錯的! --> <input type="email" name="email" required="false" />
解析器仍然會將 required 屬性視為有效並執行相應的行為，盡管你試著告訴它不要去執行了。這顯然不是你想要的。
有三種有效的方式去使用布爾屬性。（後兩種只在 xthml 中有效）
‧required
‧required=""
‧required="required"
上述例子的正確寫法應該是:
<input type="email" name="email" required />
