最近组内进行HTML5标签的学习，方法呢就是大家每人挑选几个标签，自己先去学习，然后给大家作讲解。这个过程大家还是挺有收获的。但是现在HTML5还处在草案阶段，有些新的标签元素的解释也是经常有变化，甚至标签加入/移出也很频繁(比如 hgroup)，同时现有的大的门户网站在使用HTML5方面也没有很好的范例可以参考，让大家的学习过程更摸索。下面是我在 html5doctor 上面看到的一篇文章，在目前大家懵懂的阶段，可能看看大师的讲解会更容易理解。
下面附上原文地址：Avoiding common HTML5 mistakes，作者 :Richard Clark，有疑问的地方大家可以核对英文。
在这篇文章中，我将给大家分享HTML5构建页面的小错误和不好的实践方法，让我们在以后的工作中避免这些错误。
不要把<Section>当成简单的容器来定义样式
我们经常看到的一个错误，就是武断的将<div>标签用<section>标签来替代，特别是将作为包围容器的<div>用<section>来替换。在XHTML或者HTML4中，我们将会看到类似下面的代码：
<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>
现在我看到了下面的代码样子：
<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 ），通常的做法是直接对<body>标签定义样式就像Kroc Camen描述的那样子，如果你还需要额外的元素来定义样式，使用<div>, 就像Dr Mike 阐述的那样, div并没有灭亡，如果这里没有其它更合适的，div可能是你最合适的选择。
记住这点，这里我们重新修正了上面的例子，通过使用两个新角色。（你是否需要额外的<div>取决于你的设计。）
<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来让你继续前行。
只在需要的时候使用<hgroup>和<header>标签
使用标记的时候写入了一些并不需要的现象这是不合理的。不幸的是，经常发现大家在并不需要的地方使用<header>和<hgroup>标签。你可以跟进我们关于<header>和<hgroup>的最新进展，下面是我的简单归纳：
- <header>元素通常是通常作为一组解释或者导航辅助工具，通常包含section的标题.
- <hgroup>元素会将当有副标题\子标题，各类标识文字时，对<h1>到<h6>标题进行群组，将其作为section的标题.
过度使用的<header>
你肯定知道，在一个文档中，可以使用多次<header>标签，下面就是一种很受大家欢迎的模式:
<article>
<header>
<h1>My best blog post</h1>
</header>
<!-- Article content -->
</article>
如果你的<header>标签只包含一个标题元素时，就不要使用<header>标签了。<article>标签肯定会让你的标题在文档大纲中显现出来，而且因为<header>并不包含多重内容(就像定义中描述的那样子)，我们为何要增加而外的代码呢?应该像下面这样简单才可以:
<h1>My best blog post</h1>
<!-- Article content -->
</article>
<hgroup>不合理使用
在标题的这个主题上，经常看到使用<hgroup>的错误案例。在下面这种情况下你不能将<header>标签和<hgroup>标签一起使用:
- 这里只有一个标题,
- 或者<hgroup>本身就够了(比如：不需要<hgroup>)
第一种情形看上去是下面的样子:
<header>
<hgroup>
<h1>My best blog post</h1>
</hgroup>
<p>by Rich Clark</p>
</header>
这种情况下，将<hgroup>移除，只保留标题就好.
<h1>My best blog post</h1>
<p>by Rich Clark</p>
</header>
第二种情况也是包含了他们并不需要的标签.
<header>
<hgroup>
<h1>My company</h1>
<h2>Established 1893</h2>
</hgroup>
</header>
当<header>标签的子元素只有<hgroup>的时候，为什么我们还需要一个额外的<header>?如果没有额外的元素放到<header>中(比如<hgroup>的兄弟元素)，我们直接将<header>元素去掉就好。
<h1>My company</h1>
<h2>Established 1893</h2>
</hgroup>
不要将所有的链接列表都放到<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>标签:
如果你不能确定是否使用<nav>，那就先对你问一下下面的几个问题：“这是否是一个主要链接？”，你可以根据下面的几个因素来回答你刚才的问题：
- 如果用<section>和标题标签能够解决你的问题，那就不要去使用<nav>–Hixie on IRC
- 你是不是为了增加可访问性而增加的一个快捷跳转链接呢？
如果上面的回答都是“不”，那可能就不适合使用<nav>。
<figure>元素的错误
<figure>和经常与它合伙作案的<figcaption>，是很难掌握的标签，下面是经常看到的一些小错误。
并不是所有的图片都是figure（注：比较难理解阿，image=图片，figure=图形）
之前，我曾经说过不要写那些不需要的标签。这个错误也是相同的。我经常看到一个网站上的每张图片都有<figure>标签。这些额外增加的标签并不会给你带来任何的益处，并且还增加了你自己的工作强度和让自己的内容变得更难理解。
在规范中关于<figure>的解释如下：“某些流内容，可以有标题，自我包含并且通常作为一个单元独立于内文档流之外。”在那里有完美的表述，就是它可以被从主内容中移除——比如放到边拦，而对文档流没有影响。
如果仅仅是一张表现类的图片而且和文档中其他的内容没有关系的话，那就不需要使用<figure>.”这张图片需要对上下文的内容作出解释吗？”，如果答案是”否”，那就可能不是<figure>(可能是<aside>)，“我能把它移到附录里面吗？”，如果这两个问题的答案都是”是”，那就可能是<figure>.
你的标志不是一个<figure>
将上面的延伸开来，对你的logo也是这样。下面是两组我找到的有规律的代码片断：
<header>
<h1>
<figure>
<img src="/img/mylogo.png" alt="My company" class="hide"/>
</figure>
My company name
</h1>
</header>
<!-- Don’t copy this code! It’s wrong! -->
<header>
<figure>
<img src="/img/mylogo.png" alt="My company"/>
</figure>
</header>
这里就不需要说啥了，这是很明显的错误，可能你认为我们说的是不是将logo放在H1标签里面，但是我们在这里并不讨论这个问题。让我们迷惑的是<figure>元素。<figure>标签只用在当有上下文需要说明或者被<section>包围的时候。我这里要说的是你的logo可能很少会被这种情况下使用。很简单，那就不要去这样做，你需要的仅仅是下面的样子。
<h1>My company name</h1>
<!-- More stuff in here -->
</header>
figure只能用在标签上的误解
另一个对<figure>的误解就是我们通常认为它只能用在图片上面。事实上并不是这样子的，它可以被用在 <video><audio>, 一个图标 (比如<SVG>), 一个引用, 一个表格, 一段代码, 一段散文, 或者任何和这些相关的组合。不要把你的<figure>标签仅仅局限在图片上。我们网页制作师的任务就是用标签更准确的描述内容。
这里有一篇更深入讲解 <figure>的文章I wrote about <figure>，很值得阅读的。
不要去使用那些不必要的type属性
这可能是我们最常见的一些问题，它们并不是真正的错误，但我觉得我们的最好实践还是尽量避免这种模式。
在HTML5中，我们并不需要给<script>和<script>增加 type 属性，如果这些从CMS默认添加的内容中移出是很痛苦的事情，那当你手工编码的时候还写入它们或者你能完全的控制你的模板时候你完全可以删掉它们。因为所有的浏览器都会将<script>解析成Javascript和<css>标签是CSS，你不再需要那个type属性了：
<link type="text/css" rel="stylesheet" href="css/styles.css"/>
<script type="text/javascript" src="js/scripts.js"></script>
现在我们可以写成下面的样子：
<script src="js/scripts.js"></script>
你也能够对编码的设置作出省略。Mark Pilgrim在Dive into HTML5的语义化一章中作出了解释。
不要包含错误的表单属性
你可能发现<html5>引入了很多新的表单属性。现在我就给大家讲讲一些不合适的使用。
布尔值属性
新引入的标签属性有几个是布尔类型的，它们的标签行为基本接近。这些属性包括：
- autofocus
- autocomplete
- required
坦白的说，下面的这种情况对我来说并不常见，但我们从 required 作为例子，如下：
<input type="email" name="email" required="true"/>
<!-- Another bad example -->
<input type="email" name="email" required="1"/>
基本上看，这段代码并不会带来危害。客户端对 HTML的解析遇到 required 标签属性时，他的功能就会生效。但是当我们将代码修改，录入 required=”false” 的情况呢？
<input type="email" name="email" required="false"/>
解析的时候依然会遇到 required 属性，虽然你希望加入的行为是“假”，它依然会被解析成“真”。
这里有三种合理的方法让布尔值生效。（第二种和第三种方案只有你在写 XHTML 解析的时候需要）
我们上面的例子可以写成下面的样子：
总结
对我来说，我无法将所有蹩脚的代码模式都展示在这里，但是上面说的这些都是我们经常遇到的。
转载请注明： 文章转载自：爱思资源网 http://www.aseoe.com/show-10-293-1.html
