HTML5 の歴史の詳細な探索 API_html5 チュートリアル テクニック

歴史って面白いですね。以前のバージョンの HTML では、閲覧履歴の操作は非常に限られていました。どのような方法を使用できるかを行ったり来たりすることはできますが、私たちにできるのはそれだけです。

ただし、HTML 5 の History API を使用すると、ブラウザの履歴をより適切に制御できます。たとえば、履歴レコードのリストにレコードを追加したり、更新がない場合にアドレス バーの URL を更新したりできます。
なぜ History API を導入するのですか?

この記事では、HTML 5 における History API の起源を理解します。これまでは、ページのコンテンツ、特にページにとって特に重要なコンテンツを変更するためにハッシュ値を使用することがよくありました。更新がないため、シングルページ アプリケーションの URL を変更することはできません。さらに、URL のハッシュ値を変更しても、ブラウザの履歴には影響しません。

そして、HTML 5 の History API を使用することで、これらは簡単に実装できるようになりましたが、単一ページのアプリケーションではハッシュ値を使用する必要がないため、追加の開発スクリプトが必要になる場合があります。また、SEO に配慮した方法で新しいアプリケーションを構築することもできます。さらに、帯域幅も減少しますが、それを証明するにはどうすればよいでしょうか?

この記事では、History API を使用してシングルページ アプリケーションを開発し、上記の問題を証明します。

これは、最初に必要なリソースをホームページにロードする必要があることも意味します。これ以降、ページには必要なコンテンツのみが読み込まれます。つまり、アプリケーションは最初にすべてのコンテンツをロードするのではなく、2 番目のアプリケーション コンテンツが要求されたときにロードされます。

ページ コンテンツ全体ではなく、リソースの一部のみを提供するには、サーバー側のコーディングを実行する必要があることに注意してください。
ブラウザのサポート

この記事の執筆時点では、主要なブラウザによる History API のサポートは非​​常に良好です。このリンクをクリックすると、サポートされているブラウザが表示されます。サポートされている特定の機能を検出する練習をしてください。

メソッドを変更してブラウザがこの API をサポートしているかどうかを判断するには、次のコード行を使用して確認できます:

さらに、「さまざまな HTML5 機能の検出サポート」の記事も参照することをお勧めします (追記: 後で翻訳します)

。

最新のブラウザを使用している場合は、次のコードを使用できます:

ブラウザが History API をサポートしていない場合は、代わりにhistory.js を使用できます。
利用履歴

HTML 5 では 2 つの新しいメソッドが提供されます:

1.history.pushState(); 2.history.replaceState();

どちらの方法でも履歴を追加および更新できます。機能は同じで、同じ数のパラメータを追加できます。メソッドに加えて、popstate イベントもあります。次の記事では、popstateイベントの使い方と使うタイミングを紹介します。

PushState() と replaceState() のパラメーターは同じであり、パラメーターの説明は次のとおりです。

1. state: Popstate イベントで使用できる JSON 文字列を保存します。

2. title: 現在、ほとんどのブラウザはこのパラメータをサポートしていないか、無視しています。代わりに null を使用することをお勧めします。

3. url: URL がアドレス リストに既に存在するかどうかに関係なく、ブラウザのアドレス バーを更新するために使用される任意の有効な URL。さらに、ページはリロードされません。

2 つのメソッドの主な違いは、pushState() は履歴スタックに新しいエントリを追加し、replaceState() は現在のレコード値を置き換えることです。これについてまだ混乱している場合は、いくつかの例を使用して違いを示します。

2 つのスタック ブロックがあり、1 つは 1、もう 1 つは 2 というラベルが付けられ、3 番目のスタック ブロックには 3 というラベルが付けられているとします。 PushState() が実行されると、既存のスタックにスタック ブロック 3 が追加されるため、スタックは 3 つのブロック スタックを持つことになります。

同じ仮想シナリオの下で、replaceState() が実行されると、ブロック 3 はブロック 2 のスタックに配置されます。したがって、履歴レコードの数は変化しません。つまり、pushState() は履歴の数を 1 つ増やします。

比較結果は次のとおりです:

この時点では、ブラウザの履歴を制御するために、pushState() および replaceState() イベントを無視しました。ただし、ブラウザーが多数の不正なレコードをカウントすると仮定すると、ユーザーはこれらのページにリダイレクトされる場合もあれば、リダイレクトされない場合もあります。この場合、ユーザーがブラウザーの「進む」および「戻る」ナビゲーション ボタンを使用すると、予期しない問題が発生します。

ただし、処理に PushState() と replaceState() を使用する場合、popstate イベントがトリガーされることが予想されます。しかし実際にはそうではありません。代わりに、セッション履歴を参照すると、進むボタンまたは戻るボタンをクリックするか、history.go およびhistory.back メソッドを使用するかに関係なく、popstate がトリガーされます。

WebKit ブラウザでは、ドキュメントの onload イベントの後に Popstate イベントがトリガーされますが、Firefox と IE にはこの動作がありません。

デモの例

HTML: