HTML5历史API

浏览器的地址栏可能是所有用户界面中最复杂的部分了。我们有关于账单的 URL，有火车票的 URL，还有关于街道信息的 URL。结合后退按钮——或许是浏览器最重要的按钮——你可以实现一种强大的前进、后退操作，在这个庞大的 Web 世界中自由来回。 HTML5 历史 API 是使用脚本维护浏览器历史的一种标准方法。这个 API 的一部分——历史导航——已经在早期版本的 HTML 中实现。HTML5 新增部分包括向浏览器历史添加历史记录，显式地改变浏览器地址栏（不需要页面刷新），以及当用户按下浏览器后退按钮，从堆栈中删除页面历史时发出事件等。这意味着浏览器地址栏的 URL 可以唯一标识当前资源，即使是在有很多脚本的、几乎永远不会刷新页面的大型应用程序中。

为什么？

为什么我们需要手动维护浏览器历史？毕竟，一个简单的链接就可以导航到一个新的URL。这种实现已经在 web 中超过20年了，并且现在我们还是继续这种实现。历史API也并不是要推翻这种方式。恰恰相反，在最近几年中，web 开发人员找到一种新方式，不通过标准 API 的改变就可以实现 web 革命。HTML5 历史 API 就是为了让有着大量脚本的 web 应用程序能够更好实现。 回到最初的原则，URL 是干什么用的？用唯一标识一个资源。你可以直接连接到它，可以使用书签收藏，搜索引擎可以做索引；你可以把这个 URL 复制粘贴到邮件中发给别人，他只要点击这个 URL 就可以看到你想让他看的原始页面了。听起来不错，这就是 URL 的重要之处。 所以，我们希望唯一的资源有唯一的URL。不过与此同时，浏览器却有一个限制：如果你改变了URL，甚至是通过脚本，它就得向服务器发送请求，刷新整个页面。这很耗时，也耗资源。如果你仅仅想转到一个与当前页面类似的页面，这么做无疑很浪费。新页面的所有东西都得重新下载，即使那些与当前页面一模一样的东西。我们没有办法告诉浏览器改变URL但是仅仅下载一半页面。 HTML5 历史API 能够让你这么做。在一定程度上，你可以通过脚本告诉浏览器，仅下载一半页面。这解释起来挺复杂，并且需要你做一些工作。下面来看看吧！ 假设我们有两个页面，A 和 B。这两个页面90%都是一样的，只有10%不同。用户打开了A页面，然后想打开B。这时，我们不需要整个页面的刷新，你需要截断这个导航，然后去做下面的工作：

1. 从B页面下载与A页面不同的那10%（可以通过 XMLHttpRequest）。这需要服务器端做一些修改。你需要重写代码，返回B页面与A页面不同的那10%的代码。这可以使用一个隐藏URL，或者用户看不到的查询参数。
2. 替换改变部分（使用 innerHTML 或者其他 DOM 方法）。你可能也得修改被替换部分的节点的事件监听函数。
3. 将浏览器地址栏切换成B页面的，使用 HTML5 历史API 的一个函数即可。

在上面解释的最后，浏览器已经是页面B的DOM，看起来就和直接打开页面B没什么两样。浏览器地址栏最后也变成页面B的URL，就像你直接输入一样。但实际上你并没有真的到了页面B，没有整页刷新。这就是后面隐藏的情况。但是，这个“编译后”的页面看起来就和页面B没什么两样，URL也是页面B，用户也不会感到什么不同（当然，也不会知道你为此而做的大量工作）。

怎么做？

HTML5 历史 API 是 window.history 对象的一系列方法，另外还有 window 对象的一个事件。你可以使用这些函数去测试浏览器是否支持历史API。

IE	Firefox	Safari	Chrome	Opera	iPhone	Android
-	4.0+	5.0+	8.0+	-	4.2.1+	-

dive into dogs 是一个使用 HTML5 历史API 的例子。这个页面是一个典型的例子：一篇长长的文章，配上一个关联的相册。在支持历史 API 的浏览器中，使用相册上面的 Next 和 Previous 链接可以更新相册，并且可以更新浏览器地址栏的 URL，不需要刷新这个页面。在不支持历史 API 的浏览器中——或者是原本支持历史API，但是用户禁用了脚本的浏览器中——这些链接就是普通的链接，通过刷新整个页面达到新的页面。 这是很重要的一点：

如果浏览器因为禁用了脚本而导致你的应用系统错误，小心 Jakob Nielsen 的狗会出来跑到你屋里咬你的哦~~（意思是如果因为禁用脚本而到处原本的应用程序不可用，那这个历史API就不能向前兼容了，也就没什么应用价值了。）

下面我们深入学习一下这个页面，看看是它如何工作的。下面是一张照片是如何工作的： 这里没有什么不同之处。照片使用

中的 实现，链接则使用一个常规的 元素，而这所有的元素都是在一个