[HTML] 一个通用的 HTML5 基础模板（译）_html/css

原文。

随着你学习了 HTML5 并把新技术加入到你的技能列表，你可能希望建立一个自己的模板，你可以用这个模板开始任何简单的 HTML5 项目。我们鼓励这么做，并且你可能考虑使用网上提供的关于 HTML5 开发的模板资源中的其中一个。

然而，在这个项目中，我们要重头开始构建我们自己的代码并解释每一块。当然，在各种项目中我们不可能包含每一个新的元素和技术，所以我们也要解释一些和项目不符合的新特性。通过这种方式，你将会熟悉许多广泛的选项并可以决定如何构建你的 HTML5 和 CSS3 网站和 web 应用，所以你可以把这篇文章当做一个快速参考的技术书籍。

让我们从简单的开始，下面是一个简单的 HTML5 页面：

<!doctypehtml> <htmllang="en"><head>  <metacharset="utf-8">   <title>TheHTML5Herald</title>  <metaname="description" content="The HTML5 Herald">  <metaname="author" content="SitePoint">   <linkrel="stylesheet" href="css/styles.css?v=1.0">   <!--[if lt IE 9]>    <scriptsrc="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script>  <![endif]--></head> <body>  <scriptsrc="js/scripts.js"></script></body></html>

登录后复制

有了这个基本的模板，现在让我们研究一些标记中的重要的组成部分以及他们与 HTML5 之前的语言有何差异。

The Doctype

首先，我们有文档类型声明，或者说文档类型。这是一种简单的方式用来告诉浏览器（或其他解析器）正在查看的文件类型。在 HTML 文件的情况下，这意味着 HTML 的特定版本和风格。文档类型总是应该作为 HTML 文件的第一项且放在文件顶部。许多年前，文档类型声明是一个很丑陋并难以记住和混乱的东西。比如在 XHTML 1.0 Strict：

<!DOCTYPEhtmlPUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

登录后复制

在 XTML4 Transitional：

<!DOCTYPEhtmlPUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

登录后复制

尽管在文档顶部的长字符串并不会伤害我们（只是迫使访问我们网站的人下载多几个字节），在 HTML5 中这个已经废除了这些难以辨认的字符串，现在你需要的只是这些：

<!doctypehtml>

登录后复制

简单扼要。这个文档类型可以使大写，小写，或者混合的情况。你会注意到在声明中缺少了“5”这个数字。尽管当前的 web 版本迭代被称为“HTML5”，但它只是之前 HTML 标准的一个演变 – 而且在未来的规范也会像我们今天一样演变。

因为浏览器通常需要支持网站上的全部内容，所以在给定文档的文档类型上并没有提供信息告诉浏览器他们应该支持哪些特征。换句话说，文档类型本身并不会告诉你的页面应该遵守 HTML5。它取决于浏览器。事实上，你可以使用那两个旧的文档类型声明并在页面中使用 HTML5 元素，页面呈现效果会和你使用新的文档类型声明一样。

Html 元素

接下来在 HTML 文档中的是 html元素，在 HTML5 中并没有显著改变。在我们的例子中，我们包括了 lang属性和 en属性值，用于指定文档语言是英语。在 XHTML 基本语法中，你需要包含 xmlns属性。在 XTML5 中，这不再需要了，甚至连 lang属性对于文档的验证或运行也不是必要的了。

这是我们到目前为止，包括闭合标签 ` 的模板：

<!doctypehtml><htmllang="en"> </html>

登录后复制

Head 元素

下面这部分是我们页面的部分。 head中的第一行元素用于定义文档的字符编码。这是自 XHTML 和 HTML4 后又一个简化的元素，并且这是一个可选的特征，但是建议大家使用。在过去，你可能需要这么写：

<metahttp-equiv="Content-Type" content="text/html; charset=utf-8">

登录后复制

HTML5 中通过使用标记来最大化减少字符编码声明的长度：

<metacharset="utf-8">

登录后复制

几乎在所有情况下， utf-会作为你文档使用的值。一份详细的字符编码解析已经超出了文本的范围，并且你可能不会对此感兴趣。尽管如此，如果你想深入研究，你可以在 W3C或者 WHATWG中阅读相关话题。

注意：编码声明

为了确保所有的浏览器能够正确读取字符编码类型，整个完整的字符编码声明需要用 512 个基本字符在你的文档某处写入。它还应该出现任何内容基本元素（比如我们的例子中的 title元素）之前。

对于这个话题我们还可以写更多，但我们希望你保持清醒别睡着。所以我们省略了一些细节！目前。我们的内容接受这个简单的声明并继续我们文档接下来的部分：

<title>TheHTML5Herald</title><metaname="description" content="The HTML5 Herald"><metaname="author" content="SitePoint"> <linkrel="stylesheet" href="css/styles.css?v=1.0">

登录后复制

在上面几行中，HTML5 和之前的语法几乎没什么区别。页面标题（在 head部分中唯一的强制元素）和以前的声明一样，而例子中的 meta 标签也仅仅只是可选的，用来表明这些标签应该怎么放置；你可以把尽可能多的 meta 元素放进来。

这一部分关键的标记是样式表，用 link元素来表示。对于 link元素只有 href和 rel属性是必需的。而 type属性（在以前的 HTML 中很常见）不仅不再是必须的，而且也不再需要用来表示样式表的内容类型。

Leveling the Playing Field

接下来我们要介绍的元素需要先了解一些背景信息。HTML5 包含许多新的元素，比如 article和 section，将会在以后介绍到。你可能会想这对于旧的浏览器来说可能会造成无法识别元素的问题，但你错了。这是因为大多数的浏览器并不在意你用什么标签。如果你有一个 HTML 文档使用了 recipe标签（甚至 ziggy标签），且你的 CSS 中的某些样式和这个标签相关联了，但是几乎每一个浏览器都会把这当成正常的样式，并且会严格遵守你的样式。

当然，这样一个假设的文档可能会造成无法验证并造成可访问性的问题，但在几乎所有的浏览器中它都能正确呈现，唯一的例外是旧版本的 IE 浏览器。在版本 9 之前，IE 会阻止样式表中的未识别元素。这些神秘的元素会被渲染为“未知元素”，所以你无法改变它们的表现或行为。这不仅包括了我们假想的元素，也包含了开发那个版本浏览器之前未被定义的元素。这意味着 HTML5 中的新元素也无法被识别。

好消息是，在写这篇文章的时候，大多数人已经使用了 IE9 或以上的版本，其中很少人是 IE9，所以对于绝大数开发者来说这不再是问题；但是，如果你的访问者仍然使用 IE8 或之前的版本，你必须采取行动确保你的设计不会崩溃。

幸运的是有一个解决方案：一个由 John Resig 开发的 JavaScript 模板。灵感来自于 Sjoerd Visscher 提出的一个想法，这个模板可以使 HTML5 中的元素兼容旧版本的 IE。

在我们的文档中已经使用 script标签把这个“HTML5 shiv”模板引入，并把 script标签放入了条件语句中。实现条件是只有在 IE9 或之前的浏览器版本才会触发。这些语句提供浏览器访问特定的样式或脚本的能力。接下来的条件语句告诉浏览器必和标签仅仅只有在用户使用 IE9 之前的浏览器访问时才会显示。

<!--[if lt IE 9]><scriptsrc="http://html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->

登录后复制

应该注意的是如果你使用的 JavaScript 库是用 HTML5 新特性或者新 Apis 的话，可能会提示已经存在 HTML5 脚本；这种情况下，你可以移除你脚本的引用。一个例子是 Modernizr，一个 JavaScript 库使用了最新的 HTML 和 CSS 特性。Modernizr 已经提供给你是否允许在 IE 旧版本中使用 HTML5 元素的选项，所以 shiv 会是多余的。我们可以在 Modernizr 的附录 A 中查看。

注意：不是每个人都可以从”HTML5 Shiv“中获益。

当然，还有许多用户无法从“HTML5 Shiv”中获益：那些出于某些原因禁用 JavaScript 并且使用 IE8 或之前版本的用户。作为一个网页开发者，我们应该做到网站中的全部内容应该可以被用户完全访问，甚至在没有 JavaScript 的情况下。但情况可能没有那么糟糕。许多调查表明，那些禁用 JavaScript 的用户数量比例十分低，特别是在那些使用 IE8 或之前版本的用户群体中。

在一份 2013 年 10 月份发表的一份调查中，英国国家数据服务发现那些禁用 JavaScript 或者无法使用的用户比例不到 1.1%。而在另外一份雅虎开发者网络的调查显示（发表于 2010 年 10 月），全球用户中禁用 JavaScript 的比例在大约接近 1%。